同一台机器隔几周就报一次错：内存可纠正错误累积到什么程度该换

有一类告警的出场方式非常固定：一台跑了两年左右的机器，每隔三四周就会在同一种工况下出问题——通常是深夜批处理或者月末对账那段时间，应用侧表现为几个请求超时、一个后台进程被杀掉、或者一次例行的一致性校验没通过。运维登上去查，CPU、磁盘、网络的曲线都很平淡；重启一遍，一切恢复正常。日志里只留下几行看着陌生的记录，带着「corrected error」「CE」「memory controller」这类字样。下一次出现是三四周之后，同样的机器，差不多的时间段。

这类现象之所以难处理，是因为「报错」和「故障」之间隔了好几层。现代服务器的内存几乎都带纠错码（ECC），绝大多数错误在数据被用出去之前就被算回来并纠正，业务全程无感知，只有一行计数被加了一。真正决定这台机器命运的，不是「有没有出现过这一条记录」，而是「这些记录在时间轴上排成什么形状、在空间上落在哪些物理单元上」。换句话说，这是一个需要证据、需要时间戳、需要位置信息的判断，而不是看到「ECC 报错」四个字就决定要不要换件。

「重启就好」为什么会遮住真正的信号

重启在这件事上有三个副作用，每一个都在减少信息量。

第一个副作用是证据被清零。操作系统里能看到的内存纠错计数，绝大多数是从本次启动开始累加的累计数，一旦重启就从零重新数；即使这次重启之前已经累积了几百次，重启之后站在这台机器面前的人看到的依然是一个干干净净的零。如果这个团队没有把计数定期采出来存成时间序列，那么「三四周一次」这个最关键的规律，就被一次重启彻底抹平了。更麻烦的是，绝大多数服务器上其实还有另一个证据来源被忽视了——服务器主板上那颗独立于操作系统运行的带外管理控制器，会把事件写进自己的日志并且带时间戳，重启不影响它；但它的日志是环形覆盖的，长期不导出就会丢失。所以「重启之后查不到」往往不是没发生，而是查错了地方。

第二个副作用是状态被重置。内存控制器在每次开机自检阶段都会重新做一遍信号训练（training），重新确定读写时序、驱动强度与参考电压的工作点。原本因为信号裕度不足而在特定负载条件下才出错的内存条，在训练结果变化之后可能暂时回到正常范围内。这解释了「为什么重启就好了」，同时也解释了「为什么它还会回来」：训练解决的是工作点，不是模块的物理状态。

第三个副作用是错误性质被混为一谈。位翻转里有相当一部分是偶发的：宇宙射线粒子穿过封装、封装材料里微量放射性元素的衰变、相邻存储行被反复激活带来的电荷扰动，都可能翻掉一个单元，而这条内存本身是完好的。这一类「软错误」的特征是随机分布在不同地址上，通常不需要换件；而反复命中同一个物理单元的错误，指向的是颗粒本身、焊点或者接触与信号完整性问题，属于「硬错误」，即使每次都被纠正也值得当成更换候选。重启会把这两类的地址信息一起抹掉，让下一次分析从零开始。

所以第一个应当确立的纪律很简单：怀疑内存问题时，先取数，再重启。需要取的数至少包括错误累计数、能否定位到具体颗粒、以及带外日志里最近若干条事件的时间戳。

可纠正与不可纠正：错误落在哪一侧

先把两类错误的定义说清楚。

可纠正错误（CE）指的是：内存控制器在读取时发现数据不符合校验规则，但错误的位数落在纠错码能够恢复的范围内，于是把正确值算出来、回送给请求方（多数实现还会把正确值写回原位置），并记一次计数。整个过程通常额外消耗若干个到几十个时钟周期，业务层几乎不可能感知。

不可纠正错误（UE）指的是：错误的位数超出了恢复能力，或者错误落在了系统判定为不可挽回的位置。它的后果要分两种情形讨论，因为这两种情形在运维里的表现完全不同。第一种，如果出错的数据是 CPU 正在使用的指令或内核关键数据结构，处理器会抛出机器检查类异常，在很多默认配置下直接导致整机宕机，事后只能去做取证分析。第二种，如果出错的数据属于某个用户态进程独占且干净的数据页，部分内核版本可以走「硬件错误页隔离」路径（内核里的说法是 hwpoison）：把这个页面标记为不可用、解除映射，并向该进程投递总线错误信号让它退出，整机活下来。这就是为什么有些机器会莫名其妙丢一个数据库子进程而自己还在线——不是应用写错了，是内核主动处理了一次内存故障。

还有两种更隐蔽的情形值得单独拎出来。

其一是「被巡检发现但还未被使用」的不可纠正错误。服务器固件或内存控制器通常有一套后台巡检（也叫巡逻刷洗、patrol scrub）机制，在空闲时把内存按周期读一遍。如果巡检过程中读到一个已经被判定为不可纠正的位置，它会立刻写成事件，但此时不一定有任何程序在读这块数据，所以不一定立刻宕机。这类事件极其宝贵：它是一次「提前预警」，给了运维一个还没发生业务损失的处置窗口。

其二是发生在数据通路上的错误。传输链路上的校验失败与颗粒自身的失效在日志里长得非常像，但成因完全不同——前者可能指向插槽接触不良、灰尘与氧化、信号完整性下降，甚至内存频率设置与平台不匹配。区分两者的第一步，是把「位置」和「次数」一起看：通路问题往往跟着通道或插槽走，颗粒问题往往跟着那一条走。

纠错能力有边界：为什么「能纠正」不等于「没事」

要理解「能纠正」为什么不等于「没事」，得先看纠错能力本身的结构。

ECC 的核心是冗余比特。最常见的一类方案可以纠正一个码字内的单位错误、同时检出两位错误；更强的实现会把相邻比特打散到不同的物理颗粒上，使得单颗颗粒失效、或者单个位宽范围内的连续失效仍然能够恢复——厂商通常用 Chipkill、SDDC、ADDDC 这一类名字来称呼不同强度的实现。关键点在于：这些方案提供的是「有限的容错额度」，不是一个可以无限兜底的保险层。额度用完之后，错误依然会漏出去。

额度主要被三件事消耗。第一是累积：同一个码字内出现第二个错误时，原本「一位可纠」的余量就用完了。两次本来各自可以被纠正的单比特错误，如果恰好落在同一个码字里，合并起来就是不可纠正。第二是范围：同一颗物理颗粒内部若干相邻存储单元同时变弱时，一次失效可能覆盖多个数据位，超过打散之后的容错范围。第三是时间与漏电：日子久了、温度高了，原本处在临界状态的单元会真正越过阈值。这也解释了为什么很多内存故障不是「某天突然坏掉」，而是先在日志里以极低频率的可纠正错误现身，几周甚至几个月后才升级为不可纠正。

于是可以把「能纠正」这件事理解成一句话：它保证的是「这一次读取到的数据是对的」，而不是「这块介质没有问题」。纠正动作通常会把正确值写回，但写回并不能恢复该单元的电荷保持能力，下一次读出来还是可能出错。这一点，也正是内存与磁盘之间最本质的差别，后文会专门对照。

顺着这个逻辑，还必须区分造成可纠正错误的三类成因，因为它们的处置完全不同。第一类是随机偶发的外部扰动，其规律是「总量很低、不增长、地址随机」，对应动作是记录基线；第二类是随温度与负载变化的边际失效，其规律是「只在特定工况下出现」，可以通过改善散热、降低内存占用密度、在固件允许范围内调整时序裕度来缓解；第三类是真正的单元、焊点或接触缺陷，其特征是「同一位置反复出现，并且单位时间新增数随月份上升」，这一类只能换件，等待只是把它推向不可纠正。开篇那个「三四周一次、总在深夜批处理时段」的案例，往往正落在第二类与第三类的交界处：高温加上高带宽负载让边际单元越过阈值，随着器件老化，这条曲线会慢慢从平坦变成抬升。

四条取证路径：内核计数、带外日志、厂商巡检、内存巡检

方向上可用的证据来源有四条，它们的覆盖面并不重叠，最好叠加使用。

第一条是操作系统内核里的错误检测与纠正子系统。Linux 有专门的 EDAC（Error Detection And Correction）子系统，其中一组驱动负责读取各平台内存控制器的错误计数寄存器，并通过 sysfs 暴露出来。能读到什么，取决于这台机器所用的 CPU 与芯片组是否被对应的驱动支持——有些服务器处理器有可用的 EDAC 驱动，有些平台则需要厂商自己提供对口的驱动，有些只能读到粗粒度甚至完全读不到。所以排查的第一步永远是确认「这台机器的 EDAC 到底有没有在工作」，而不是默认它一定能看。

从这套接口里要拿三类信息：控制器级别的可纠正计数与不可纠正计数（每个控制器节点各一份）；按通道、按行、较新内核还要按内存条细分的计数（用来判断错误是不是集中在某一段）；以及标签信息——即能否把「第几个控制器的第几行第几通道」翻译成机箱丝印上的第几个插槽。没有标签，定位粒度只能到「这一侧通道」；有了标签，才能到具体插槽。这一步通常不需要停机，是完全可以先做的准备工作。

这条路径有两个必须记住的限制。其一，计数是自启动累加的、不带时间戳，只有按固定间隔把它采出来并自己存成时间序列，才能算速率；其二，它只在系统活着的时候存在，机器宕机重启、系统重装之后一律归零。

第二条是带外管理口的日志。主板上的带外控制器独立供电、独立运行，会把内存相关事件写进自己的系统事件日志并附带时间戳。相对内核计数，它的优势是主机宕机它还在、重启之后还能回溯历史，而且它记的是「事件」而不是「累计值」，更适合回答「那一次故障究竟发生在什么时刻、当时有多少条」。它的劣势是粒度：许多平台只写到通道或插槽组，不一定写到具体插槽；而且这类日志多为环形缓冲，长期不导出会被覆盖。运维上应当把它当成必须定期收集的对象，而不是只留着给售后看。

第三条是服务器厂商的巡检视图与离线诊断工具。多数整机厂商在带外管理界面里提供硬件健康总览，也提供可引导的离线内存诊断程序。它的价值在于：在没有业务负载的状态下，用可控的模式去覆盖全部地址空间，从而回答「是不是大面积问题」。它的局限同样明确：一次通过不代表未来不出错，因为边际失效本来就与负载、温度、时序裕度耦合。因此厂商巡检更适合用来「排除系统性隐患」和「给售后提交工单提供凭据」，而不是用来排除单条内存的故障。

第四条是内存巡检与刷洗机制本身。这套机制由内存控制器或固件实现，按周期在后台把内存读出来，发现单比特错误就纠正并写回。它的正面意义很直接：长期不被读取的单元上，一个单比特错误会悄悄积累，直到某一天与另一个比特叠加成多比特错误，巡检能把它在还只有一位的时候就消掉，从概率上压低不可纠正错误的发生。它的代价是可讨论的带宽占用：后台读要吃掉一部分内存带宽，在本身内存带宽吃紧的业务上会表现为轻微的吞吐下降，因此部分固件默认关闭它，或者只在特定的可靠性配置里开启。排查时务必先确认这台机器的巡检到底开着没有——一台长期关闭巡检的机器，日志干净不等于健康，也可能只是错误还没被发现。

务实的最低组合是：内核计数负责细粒度定位，带外日志负责带时间戳的回溯；如果再叠一层把内核可靠性事件按时间戳落到数据库里长期保存（内核社区有这类事件采集守护进程与配套工具），那么后面所有的速率判断才有可靠数据可依。

先看它在哪：单条、同条、跨条与同插槽

拿到证据之后的第一步不是定阈值，而是定位置。同样是一段时间内几百次可纠正错误，均匀散落在十几条内存上与集中砸在一条上，是两个完全不同的故事。

需要说明的是，这张表里刻意不写任何临界数字。可纠正错误「多少条算多」在不同平台之间差异极大：颗粒数量、内存总量、巡检是否开启、负载的内存带宽压力、机房的进风温度，都会改变同一台机器上可接受的基数。可以引用的只有两类依据：厂商维护手册里对报警级别的说明，以及自己这台机器、同一批次机器过去一段时间的历史数据。

看速率而不是看条数：观察窗口怎么定

第二个判断维度是时间。只看「累计纠正了多少次」几乎没有意义：一台跑了两年、累计三百次的系统，与一台上线三周、累计三百次的系统，处境完全反过来。

正确的做法是设定固定长度的观察窗口，在每个窗口结束的时刻读一次计数，然后把相邻两次的差值换算成单位时间新增数，并画出这条曲线的形状。窗口长度如何确定，建议按厂商建议与自身基线判断，但有两条经验边界值得遵守：对于负载周期性明显的机器（例如每天夜间批处理、每月出账），窗口至少要覆盖一个完整周期，否则会把「特定工况下才出现」误判成「持续增长」；对于已经怀疑有问题的机器，窗口可以缩短到一两天，以便加快决策，但要清楚代价——短窗口更容易被噪声干扰，需要结合位置信息一起看。

判断「是不是在加速」，比判断「绝对值高不高」重要得多。同样是这条插槽一个月二十次，如果过去三个月分别是五、十、二十，那么它是抬升的，属于应当排进近期窗口的对象；如果一直稳定在二十上下、只有小幅波动，那么它更像一个与工况绑定的边际缺陷，可以有计划地安排、也可以先从散热和内存占用密度入手验证。反过来，如果几百次错误在两个月里均匀发生、且地址随机分散，那就更接近正常的软错误背景水平，只需要维持记录。

还有一条操作纪律必须明确：换件排查期间，尽量不要用重启作为恢复手段。每重启一次，速率曲线就被截断一次，前一段数据作废。正确顺序是先取数、先导出带外日志，再考虑恢复手段。如果业务侧确实无法忍受等待，至少把当时的内核计数、时间戳与带外事件的三份数据保存下来。

换之前先做的事：迁移顺序、备件与型号兼容

一旦判定要动件，顺序比速度重要。推荐的序列是这样的：先把有状态的服务迁走——数据库类从机优先，能够根据其他副本自动重建的缓存类可以降低优先级——让这台机器进入「可以被随时下电」的状态；接着确认厂商对这个机型的要求，绝大多数机架服务器的内存更换必须整机下电，少数支持分区隔离的机型才有在线更换的空间，据此去申请合适的窗口；最后才是开箱换件。把顺序倒过来的团队，通常会在业务还在跑的时候被迫硬停机。

备件环节有三个常被低估的坑。

其一是合规性：一定要在该机型的合格供应商清单范围内选型。内存的 rank 数、颗粒位宽组织（x4 或 x8）、容量、速率、以及是否寄存器缓冲（RDIMM、LRDIMM 与无缓冲的区别），都会直接影响能不能混插、混插之后是否降频、甚至能否点亮。看起来参数相近的两条内存在特定主板上可能完全不兼容。

其二是填充顺序：不少平台对插槽的填充顺序有硬性要求，临时少插一条、或者插在不符合手册规则的位置，可能直接无法开机。这意味着换件不是「拔一条插一条」这么简单，必要时要把其余几条重新按规则排布，工作量远超预期。

其三是批次相关性：同一批采购的机器往往用同一批内存。某一台的失效有可能只是批次性问题的前兆，备件储备要考虑这个相关性，而不是机械地备一件。

换完之后不要只看「起来了」。验收至少包含三项：固件自检阶段是否完成内存重训练，识别到的容量与频率是否与预期一致；带外日志里有没有新增的内存相关事件；业务回到典型负载之后，再观察一个完整的业务周期，确认纠正计数不再增长。还有一点容易被忽略：如果换下来的旧件在离线复测里完全通过，也不要简单判定为「误判」——插拔本身解决的可能是接触氧化、插槽污染或轻微的形变，这些同样属于需要在计划内处理掉的隐患。

成本上讲，真正的开销通常不在内存零件本身，而在计划外停机带走的业务量。一次可控的深夜换件，与一次白天的突发不可纠正错误造成的整机重启、进程隔离和可能的数据恢复相比，代价差着一个量级。这也是为什么建议它在还处在「疑似」阶段时就被排进计划窗口。

内存这类「能纠正但会累积」的故障，一万网络（深耕 19 年，成立于 2007 年）能做的是把带外日志与更换窗口准备好，让客户在计划内换件，而不是在故障后抢修。

对托管与物理机用户来说，第二处可以预先谈清楚的环节是：带外管理通道是否常年可用、事件日志能否按需导出、以及计划窗口内的下电与上架能否由机房侧代为执行。这几件事决定了「从发现问题到完成更换」的时长能不能被估算出来，而这个时长正是容量规划里最缺的一块。

云主机看不到底层计数时，签约要问什么

到这里必须说清一条边界：如果使用的是虚拟机形态的实例，包括所谓的独享型，上面这些计数绝大多数对租户不可见。客户机内部既没有对应的设备寄存器，也没有权限读取宿主机侧的纠错计数接口。内存故障在虚拟化环境下的表现通常是宿主侧做出反应——把受影响的实例迁移走，或者暂停、重启它——而租户看到的就是一次没有调用栈、没有应用层错误、日志里只有时间戳的重启。

这就形成了一个不对称：物理托管方可以自己取证、自己定策略；云服务的租户只能依赖服务商的通报与工单。既然依赖通报，那么签约与交接阶段就有六件事必须问明白，并且要拿到书面答复，而不是销售口头的一句「我们有监控」。

第一，是否会主动通报内存相关的硬件事件？通报渠道是控制台、工单还是邮件，通报时限多长，能否提供事件摘要的导出件。

第二，宿主机是否开启了内存巡检（刷洗）机制。开启与否直接决定错误是「在还只有一位时被发现」，还是「攒到不可纠正才炸出来」。

第三，发现可纠正错误累积之后的处置策略是什么：继续观察、计划迁移还是立即换件，触发条件能不能用文字描述出来。这一条在实际故障中最能拉开差距——它决定了「这台宿主机上的实例什么时候才动」是不是一个可预期的动作，而不是全凭对方判断。

第四，计划性维护的提前通知时长与可选窗口。如果是可协商窗口，最短需要提前多久申请。

第五，同一业务的多台实例能否申请反亲和，落在不同的宿主机上。一次宿主侧的内存故障如果同时带走同一服务的多个副本，那就从硬件事件升级成了业务事故，这是完全可以靠交付前的约定规避掉的。

第六，历史带外事件能否归档下载。拿不到归档，租户就没法建立自己的速率基线，只能无限依赖对方。

反过来说，选择物理托管的团队也要清醒：可观测性更强的另一面是责任更重，所有证据、所有基线、所有更换决策都由自己承担。这两种形态没有优劣，区别在于能不能把相应的能力配置到位。

磁盘有重映射，内存没有：判定逻辑哪里一样、哪里不一样

已经有一批文章讲过磁盘的 SMART 与阵列卡：重映射扇区计数、待映射扇区、接口校验错误的变化速率。把两者放在一起对照，反而更容易看清内存为什么不能用同一套直觉。

先看共同点。两者都看变化速率而不是单条记录。一个静态的 SMART 属性值、或者一次接口校验错误计数，本身不构成判断依据，重要的是它在一天、一周里的增量；内存完全一样，累计的纠正次数没有意义，单位时间内的新增才有意义。两者还共享同一个工程难题：原始属性通常不带时间戳，必须自己按固定间隔轮询、自己存时间序列，否则所有分析都无从谈起。两者也都把「是否有相同位置反复命中」当成最硬的证据。

再看本质差别，这也是全文的核心对照：磁盘拥有一种「缓冲机制」。当一个扇区读不稳的时候，控制器可以把这个逻辑块地址重定向到预留区域，也就是重映射；一旦重定向完成并写入新数据，此后访问这个逻辑地址读到的就是好介质。换句话说，磁盘有能力把一个已经确认的坏位置「永久换成一个好的」，坏事到此为止，后续只需盯着新增重映射的速度。行业里「少量已重映射的扇区可以接受、仍在增长的重映射才需要警惕」这句话，正是建立在这个缓冲机制之上的。

内存没有等价物。ECC 的纠正发生在「这一次读取」上：控制器算出正确值、可以把正确值写回、并记一笔事件，但这个物理单元依然留在使用序列当中，没有被替代的逻辑地址。写回只是把正确数据重新写入同一个弱单元，下一次保持期结束时它仍有可能再次出错。也就是说，内存的坏位置既不会被标记，也不会被移出使用，它会被反复读写，直到某一次超过纠错额度为止。

这个差别直接导致判定逻辑分岔。磁盘思路下，警戒线画在「仍有待映射扇区」与「重映射计数仍在加速」上，因为已经完成的重映射意味着这个坏位置已经从使用序列里被切掉了；内存思路下不存在「已经修复」的等价状态，警戒线只能画在「错误是否反复命中同一物理单元」与「速率是否在加速」上。内存里「同一地址反复出现」的坐标，等价于磁盘里「pending 扇区」的坐标——它说明这个地方确实有问题，而不是一次偶发扰动。

还有一处在吞吐量上的差别：后果的传导速度不同。磁盘出错通常表现为 IO 报错、超时或阵列降级，业务有机会在上层重试、从副本读、或者把请求挪走；内存出错一旦越过纠错额度，落点可能是一条指令、一个内核数据结构、或者一个正在被写回的脏页，后果从「丢一个进程」到「整机重启」不等，而且应用层往往拿不到有意义的错误信息。同样是「慢性硬件退化」，内存给出的整改窗口更短，也就更依赖提前取证。

最后一处相似点也值得一提：两者都会被实现方式影响观测。磁盘上，是否做了阵列、阵列卡是否透传 SMART，决定了能不能看到底层计数；内存上，是否开启巡检、EDAC 驱动是否匹配这个平台、机器是不是跑在虚拟化层下面，决定了能不能看到错误。观测不到不等于没有发生，这一点两边完全一致。

换与不换的分界线画在哪里

把前面的逻辑收敛成几条可以直接执行的判据。

可纠正错误要不要立刻换？绝大多数情况下不需要立刻换，但需要立刻开始记录。真正决定动不动手的是两个变量：错误是否集中在同一物理位置，以及单位时间新增数是否在抬升。只有这两个变量同时成立，才进入近期更换清单。孤立的一条记录、一次偶发的计数增加，既不能证明有问题，也不能证明没问题。

重启之后计数清零怎么办？清零本身不可怕，可怕的是没有任何地方保留了历史。应急的做法是立刻去调带外控制器的事件日志，它通常还带着此前的时间戳；长期的做法是把内核计数按固定间隔采集成时间序列，并且定期导出带外日志归档。

怎么看错误集中不集中？粒度由粗到细依次是：控制器、通道、行或内存条、明确到插槽丝印。能否走到最后一级取决于驱动是否报告到颗粒粒度，以及有没有维护一套把逻辑编号翻译成物理插槽的标签表。没有标签表的时候，至少要做到「确认是否集中在同一控制器或同一通道」。

带外日志拿不到怎么办？先把长期方案补上：定期导出并落到宿主机之外的地方，避免环形覆盖；短期内如果完全拿不到，只能退回到内核计数加定期快照，代价是失去时间戳精度，速率判断要相应放宽松，并倾向于更早而不是更晚地在计划窗口处理。

云主机怎么判断？租户侧没有直接证据，唯一可用的是间接信号：同一实例反复无原因重启、进程在没有应用层异常的情况下被终止、同一宿主机上的多台实例同时异常。把这些当成工单的线索提交，并要求对方给出硬件层面的说明，比在自己系统里反复排查有效得多。

内存巡检会不会影响性能？会因为占用一部分内存带宽而产生轻微影响，同时也会因为提前发现并纠正单比特错误而降低不可纠正错误的概率。是否开启取决于业务对带宽敏感度与对可靠性的要求；关键在于先确认当前开关状态，避免「日志干净」被误读成「没有问题」。

和磁盘坏道的处理思路有什么不同？最大不同是磁盘有重映射这个缓冲，坏位置可以被永久替换，因此只需要在意新增速度；内存没有这层缓冲，坏位置会一直被使用到超过纠错额度为止，因此对「同一位置反复命中」要格外敏感，处置窗口也更短。

本篇事实来源：纠错计数与处置口径怎么核对

内核侧的机制与接口口径，可以查 Linux 内核源码文档中的 EDAC 子系统说明与 sysfs ABI 文档，重点是错误计数节点的层级结构、标签（label）机制的作用，以及不同平台驱动支持范围不一致这一条限制。

不可纠正错误为何会表现为「进程被杀而整机存活」，可以查内核关于硬件错误页处理与内存故障恢复的说明；相应的处理器侧行为，需要对照具体 CPU 厂商的机器检查架构（MCE）文档，各代产品在何种条件下导致整机停机、何种条件下可被内核恢复，均以厂商手册为准。

纠错能力的边界（单比特纠正、双比特检出、以及把相邻比特打散到不同颗粒上的更强实现），依据主要来自 JEDEC 的内存标准文本与各 CPU、内存厂商的可靠性特性白皮书，Chipkill、SDDC、ADDDC 这一类名称属于厂商实现，不同代际的定义并不完全相同，引用时应当注明平台。

温度与保持时间的关系、以及相邻行反复激活导致位翻转（行业称为 row hammer）的现象与对应的目标行刷新缓解机制，属于公开的器件可靠性研究内容；这里只引用其定性结论，不引用任何具体数字。

后台巡检（patrol scrub）的存在与否、是否默认开启、开关带来的影响，以具体机型固件手册和厂商 RAS 文档为准；同一品牌不同代际的默认策略都可能不同，不能跨机型套用。

带外日志的字段名、可用时长与导出方式，依据 IPMI 类规范与具体 BMC 厂商的手册；能否写到插槽粒度是平台相关的，不要预设。

最后重申一条：本篇没有给出任何「超过多少次就该换」的具体阈值，因为这类数字必然依赖颗粒密度、内存总量、巡检开关、机房温度与业务负载，脱离具体平台引用反而有害。可执行的做法是三条并行——按厂商建议设定报警级别，按自身历史建立每台机器的速率基线，按「是否重复命中同一位置」和「速率是否抬升」这两个变量做最终决策。