核心用法
Deep Debugging 是一套强制结构化的调试方法论，将调试过程拆解为四个不可跳过的阶段，杜绝"试试看"的盲目修复：
PHASE 1 — 收集证据（只观察，不触碰）
强制回答四个问题：发生了什么、何时发生、应该发生什么、最后改了什么。必须基于真实日志、代码、环境变量，而非猜测。
PHASE 2 — 形成假设（强制步骤）
必须书面化一个可证伪的具体假设，格式为"因为[具体原因]，我将通过[具体测试]来证明/证伪"。模糊假设如"认证有问题"必须重做。
PHASE 3 — 二分搜索定位
将问题链条从中点切开（API: Middleware→Guard→Controller→Service→DB；前端: Action→State→API→Response→UI），逐段验证，用✅❌标记进度。
PHASE 4 — 最小修复
仅修复已证实的根因，禁止边调试边重构，修复后立即测试验证。
显著优点
1. 根治反复修复失败：强制要求3次修复失败必须回到Phase 1重新假设，打破"修修补补"的死循环
2. 可复现性保障：标准化DEBUG REPORT格式要求记录证据链，便于团队审计
3. 知识沉淀：附带JWT/Session/HTTP状态码等常见错误速查表，及git bisect等实用命令
4. 跨框架通用：方法论本身与语言/框架无关，适用于NestJS、Next.js、数据库、前端等全栈场景
潜在局限与风险
- 学习曲线陡峭：对简单Bug（如拼写错误）显得流程过重，可能降低小问题的修复效率
- 强制纪律成本：要求"Phase 1完成前绝不触碰代码"，在紧急生产故障场景下与"快速止血"需求存在张力
- 假设质量依赖经验：Phase 2的假设若方向错误，二分搜索效率会大幅下降
- 无自动化集成：目前为纯方法论文档，未与IDE、日志系统集成
适合人群
- 调试复杂认证/会话/权限问题的开发者
- 经历过"修3次仍失败"挫折的中高级开发者
- 需要向团队传授结构化调试思维的Tech Lead
- 处理间歇性、难以稳定复现Bug的场景
常规风险提示
⚠️ 紧急场景适配：生产环境P0故障时，可考虑并行执行"快速止血"与"深度调试"双轨，止血后立即补全完整流程
⚠️ 假设验证陷阱：避免"证实偏见"——设计测试时优先思考"如何证伪我的假设"而非"如何证实"