Systematic Debugging 是一套结构化的调试方法论，目标是用有条理的流程替代随机修改代码的做法。
流程概览 该方法论把调试分为五个阶段。
一、复现（Reproduce） 在任何其他动作之前，先可靠地复现缺陷。需要获取触发问题的确切步骤，记录预期行为与实际行为，确认问题是否稳定出现（而非偶发），并记录运行环境（操作系统、Node 版本、浏览器等）。其原则是：无法复现就无法修复，需要索取更多细节。
二、隔离（Isolate） 缩小缺陷所在范围。资料列出多种隔离手段： 二进制搜索（Binary search）代码库：注释掉系统的一半，看缺陷是否仍然存在；若存在，缺陷在剩余一半中，重复该过程；若不存在，缺陷在被注释掉的一半中，重复该过程。 Git bisect：提供了完整的命令序列，包括 git bisect start、git bisect bad、git bisect good <sha>，Git 会自动检出中点提交供测试，重复标记 good/bad 直到找到第一个坏提交，最后用 git bisect reset 结束。 按层隔离：判断问题在前端还是后端（查看网络面板）、是否在数据库（直接查询）、是否在 API（用 curl 请求端点）、是否在组件（单独渲染）。
三、假设（Hypothesize） 提出具体且可测试的假设，格式为「缺陷由 X 引起，因为 Y」，而不是模糊地说「数据有问题」。示例：「userId 为 null，因为鉴权中间件在该路由上未运行」。
四、验证假设（Test the Hypothesis） 编写能证明或证伪假设的最小测试：在怀疑位置加 console.log 或断点，检查可疑变量的值。若假设错误，带着新信息回到第三步；若正确，即找到缺陷。
五、修复并验证（Fix and Verify） 应用最小修复，验证原始复现步骤不再触发缺陷，检查是否引入回归（修复是否破坏了其他功能），并编写一个本可捕获该缺陷的测试。
调试工具对照 资料给出场景与工具的对应：问题「以前是好的」用 git bisect；「不知道代码在哪里运行」在可疑函数的入口和出口加日志；「数据看起来不对」在每一步转换处检查；「只在生产环境失败」对比环境变量、查看日志、尝试用生产数据在本地复现；「问题是偶发的」排查竞态条件、时序问题或未初始化状态；「错误信息没用」在代码库中搜索该错误的抛出位置。
常见缺陷模式 包括：差一错误（数组下标、分页、日期范围）；null/undefined（缺少可选链、未初始化状态）；竞态条件（异步操作以意外顺序完成）；过期闭包（React useEffect/useCallback 捕获旧值）；类型强制转换（== 与 ===、字符串与数字比较）；缺少 await（忘记对异步函数加 await）；环境不匹配（本地可用，CI/生产因环境变量或版本不同而失败）。
规则 资料列出四条规则：绝不猜测，始终用证据验证；修复根因而非症状；若 15 分钟没有进展，退一步重新隔离；记录尝试过的内容，避免重复已失败的思路。