调试、缺陷与回归验证：从“好像坏了”走到证据
用户说：“收藏有时保存不上。”如果立刻加一个重试循环，可能只是把重复请求变多，真正原因仍然存在。调试要先把现象变得具体，再逐步缩小可能原因，最后证明修复有效。本章练习这条思路。
1. 写一份别人能复现的问题描述
先记录使用环境、账号类型、操作步骤、预期结果和实际结果。例如：“手机浏览器，已登录，在网络断开时点击收藏，按钮显示已收藏；重新联网刷新后记录消失。”它比“收藏不稳定”更能指导调查。
不要把密码、完整访问令牌或个人数据贴进问题单。可以使用测试账号、脱敏请求标识和发生时间，让维护者在受控日志中查找。截图能说明界面现象，请求状态和相关日志能进一步说明系统发生了什么。
2. 把一次操作拆成几个检查点
沿着按钮、请求、服务端、数据库、响应逐段确认。按钮有没有发请求？服务端有没有收到？是否通过授权？数据库是否提交？页面是否正确解释结果？
现象：断网时显示“已收藏”
猜想：页面在请求完成前就更新了成功状态
实验：让保存请求明确失败，观察是否恢复原状态
证据：请求失败，但成功提示仍保留
修复方向：区分保存中、已保存与保存失败
猜想是待验证的解释，日志是证据的一部分，两者不要混写。“肯定是数据库慢”不是证据；能定位到具体请求和时间范围才有帮助。
3. 一次改变一个重要条件
如果同时升级依赖、改缓存、加重试，再发现问题消失，你很难知道哪项有效。先选择最能区分两个猜想的实验。例如用稳定测试数据排除内容差异，再模拟失败检查界面分支。
对于“旧版本正常、新版本异常”，可以逐步缩小引入问题的提交范围。Git 的二分查找能帮助缩小候选范围，但前提是有相对可靠的好坏判定；一个随机失败的测试不能轻易给每个提交贴上好坏标签。
4. 修复前先让问题被检查抓住
如果错误发生在响应失败后，增加一个保存失败用例，确认旧实现会失败。然后修改状态处理，再运行该用例与相关回归测试。“回归”关注的是改动后原本正常的行为有没有退步。
还需要考虑相邻情况：第一次请求失败、第二次成功，提示能否恢复？前一个慢请求晚到，会不会覆盖后一次操作？针对证据扩展检查范围，不必因为修了一个提示就重测所有与之无关的页面。
5. 区分缺陷严重程度与处理优先级
泄露其他用户收藏通常比按钮间距不齐严重；但优先级还要结合是否正在发生、影响人数、是否有绕行办法和修复成本。严重程度与优先级相关，却不是完全同一个维度。
紧急故障可能先通过关闭入口止损，再做彻底修复。临时措施要记录到期条件与后续负责人，否则很容易永久留下一个大家忘记的开关。
6. 修好后留下结论
问题单最后补上原因、修复内容、验证方法以及影响范围。不要只写“已修复”。一个可用结论是：“失败响应未恢复乐观状态；新增失败提示和状态恢复；断网、成功重试及重复点击检查通过。”
如果不能稳定复现，就诚实写明已经排除什么、仍缺什么证据。缺少证据时不该宣布确定根因，也不该为了关闭问题单把它归咎于用户操作。
练习与参考答案
用户刷新后收藏出现了，这是否证明刚才按钮失败提示错误？不一定。请求可能已经在服务端成功，但响应在途中丢失；也可能是更早的一次保存。需要结合请求标识、服务端记录和读取结果判断。网络失败不必然等于操作未执行，重试设计因此需要明确重复请求语义。