失败状态位背后不止一种原因
NAND 返回编程失败时，固件拿到的只是“没写成功”这一个事实。原因可能是编程脉冲不足以把阈值电压推进目标窗口，可能是相邻字线的编程干扰把已完成的分布挤出边界，也可能是单元经过大量擦写后隧穿氧化层退化到写不进去。三者的处置代价差别很大：前两类通常换一个物理位置重写就能通过，第三类换到同一 Block 的其它页大概率还是失败。一刀切判坏块会吃掉预留空间，一刀切重试则把数据留在已经不可信的区域里。
重试的两个边界
重试被限制在次数与位置两个维度上。同一目标位置的重试次数设得很低——重复施加编程脉冲本身会加剧对邻近单元的干扰；超过阈值立即改为换页重写，换页仍失败则把整个 Block 从可用池摘出，由预留的备用 Block 顶替，上层不感知。判定时会一并读取该 Block 的擦写计数与近期错误历史：擦写次数还很低的 Block 突然连续失败，更像温度或供电瞬态一类的外部因素，值得记录而不是直接丢弃；已接近寿命末期的 Block 则应尽早退役。
失败时源数据还在不在
编程失败可恢复的前提，是源数据尚未释放。写缓冲在编程校验通过之前不释放对应条目，这条规则与掉电保护属于同一套逻辑：PLP 保证异常掉电时缓冲内容能落盘，缓冲保留策略保证编程失败时还有源可搬。补写过程本身也在端到端保护覆盖之下，T10 DIF/DIX 的保护信息随数据一同迁移，避免修复动作反而引入新的静默错误。
增长率而不是单次事件
单次编程失败说明不了什么，趋势才说明问题。固件按时间窗口统计新增坏块数并写入 SMART 与 Telemetry，运维侧可以在盘仍能正常服务时把它排进更换计划，而不是等预留空间耗尽后被动响应。J750/J770 目前处于产品定义/EVT 阶段，这部分处理逻辑与各级阈值正在工程平台上按不同温度区间与擦写深度逐点标定。