触发条件消失，空列表不再靠文案掩饰。
调试与质量 · 修复与防回归
根因分析Root Cause Analysis
根因分析用证据区分症状和触发条件；只有改掉会让问题再出现的那个条件，才算可以结案。
先认出这张空订单列表，再问它为什么空
下面就是账号 B 的订单页。只加空状态时列表仍空；补上缓存键的 userId 后，三行订单长回来。
还没有订单
- 列表为空
- 缓存命中
- 键缺 userId
!账号 B 看到空列表
根因分析要区分症状和触发条件。空列表和空状态文案都长在列表上；换账号后订单回来，才证明修到了键。
知识点：症状、直接原因、根因要分开
上面的列表已经演示了核心关系，这里只给可复用的命名。
- 空列表是症状，缓存命中是直接原因，键缺 userId 才是根因。
- 只改文案或加空状态，换账号还会复发。
- 修复后要用同一对照（换账号）验证触发条件消失。
什么时候用、怎么用
故障会换账号、换时间复发，或修完仍像没修时，做根因分析，而不是先加提示。
- 信号：空状态「修好了」，但下一个用户还是空。
- 不适用：还没有稳定复现，或没有任何对照证据。
- 最短路径：固定症状 → 列为什么 → 改触发条件 → 用原对照复验。
正反例：同一空列表，只改你修的是症状还是键
目标都是让账号 B 看见自己的订单。差别只在换账号后列表会不会回来。
界面好看了，换账号仍读到错误缓存，问题会在下一个用户身上复发。
快速自测
订单列表偶尔为空，空状态文案已经写得很友好。怎样判断还没找到根因？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。