电荷是怎么被“读”坏的
读取某一页时，同一 Block 内其他字线必须被抬到高于所有编程状态的通过电压 Vpass，才能让未选中的单元导通。这个电压持续施加，会向电荷存储层注入少量电子。单次影响可以忽略，但同一 Block 被反复读取上万次之后，那些从未被写过的相邻页，阈值电压分布会整体右移，离被读页最近的几条字线偏移最明显。表现出来就是一个反直觉的现象：数据一直没动，原始误码率却在缓慢爬升。
计数粒度是一道元数据预算题
防护的前提是知道哪个 Block 读得多。最简单的做法是每 Block 一个读计数器，超阈值就整块搬走。粒度更细的做法按字线组或子块计数，能显著减少不必要的迁移，代价是元数据体积和更新开销同步上升——这些计数器要么常驻 DRAM 占用本就紧张的空间，要么周期性落盘，而且掉电后必须能恢复到一个偏保守的安全值。工程上通常分层处理：粗粒度计数常驻，细粒度信息只在候选 Block 上按需展开。
阈值定早定晚都要付代价
阈值定低，迁移频繁，读密集负载被自己触发的搬移写放大反噬，对 1 DWPD 定位的 J750 这类产品尤其不划算；阈值定高，页面误码率跨过 LDPC 硬判决的能力边界，落进软判决路径，单次读取延迟从 65 µs 量级跳到明显更高的水平，最先崩掉的就是 P99.9。更稳的判据不是只看计数：让计数决定“什么时候去看一眼”，让后台巡检读到的实际误码率决定“要不要现在搬”。
对读密集负载意味着什么
CDN 回源、推理侧的模型权重读取、向量索引这类负载的共同特征是热数据集合小而访问高度集中，恰好是读干扰最容易累积的形态。X7/X9 这类定位元数据、日志与缓存层的产品，因为写入耐久高、数据周转快，天然规避掉一部分风险；而数据长期驻留的容量型盘更依赖读计数与后台刷新的配合。相关策略目前在 EVT 阶段以定向读压力脚本验证，数据完整性目标为 UBER ≤1 扇区/10^18 bits 读。