#Bug 调试技巧 — 技能组合拳

❌ 看到报错 → 猜原因 → 改代码 → 不行 → 再猜 → 再改
✅ 看到报错 → 复现 → 收集证据 → 列假设（按概率排序）→ 逐条排除 → 修复根因

阶段 1：根因调查
  ├─ 读懂错误信息（不是扫一眼，是逐行理解）
  ├─ 稳定复现（写最小复现步骤）
  ├─ 检查 git diff（这个 bug 是不是我刚刚引入的？）
  └─ 追踪数据流（数据从哪来、经过谁、到哪去）

阶段 2：模式分析
  ├─ 找项目中类似功能的正确实现作为参考
  ├─ 对比"能跑的部分"和"报错的部分"的差异
  └─ 缩小范围到具体的函数/模块

阶段 3：假设与验证
  ├─ 列假设表（按概率排序，至少 3 条）
  ├─ 逐条设计最小验证方案
  ├─ 验证一条 → 确认或排除 → 下一条
  └─ 3 条都排除 → 重新回到阶段 1

阶段 4：实现修复
  ├─ 先写一个会失败的测试（复现 bug）
  ├─ 写最小修复让测试通过
  ├─ 跑全量回归
  └─ 记录根因和预防措施

报错 → systematic-debugging 自动激活 → 4 阶段追溯 → 修复
     → verification-before-completion 拦停（跑测试确认）
     → /code-review 扫一眼有没有引入新问题

> 这个接口报 500 了，日志：NullPointerException at UserService.java:42
> 帮我 debug

报错（深层）→ systematic-debugging 定位到症状
            → root-cause-tracing 沿调用栈逆向追踪
            → 生成 DOT 调用图，标注数据流向
            → 在源头修复（不是报错点）
            → reproducible-test-case 写成可复现测试
            → verification-before-completion 验证

> 订单接口偶尔返回 400，但不是每次。日志看不出原因。
> 帮我用 root-cause-tracing 追踪完整调用链。

偶发 bug → reproducible-test-case 设计复现条件
         → 找到稳定触发方式
         → systematic-debugging 正常追溯
         → 如果还是间歇的 → 加日志、加 trace、跑 N 次
         → /loop 跑 50 次测试直到复现

> 这个测试有时候绿有时候红，帮我找规律。
> 先跑 /loop run this test 50 times and collect every failure

"这个接口慢" → 先测量（不是猜）
             → 加计时代码或用 APM 数据定位慢的环节
             → LSP: incomingCalls 找到谁在频繁调
             → codegraph: trace 数据流看有没有 N+1
             → 精确修复，再测量
             → verification: 确认修复后的耗时

> 订单列表接口 /api/orders 返回 2.3s，帮我定位瓶颈。
> 先用 codegraph trace 分析调用链，找到耗时最长的环节。

"页面白屏/渲染不对" → agent-browser: snapshot 确认当前 DOM 状态
                   → agent-browser: screenshot 截图存证
                   → LSP: diagnostics 检查类型错误
                   → LSP: goToDefinition 追踪数据来源
                   → Chrome DevTools: console 日志
                   → 修复 → agent-browser: 重新截图验证

> 用户管理页面在筛选条件为空时白屏了。
> 帮我用 agent-browser 打开页面，截图确认当前状态。
> 然后用 LSP diagnostics 检查有没有类型错误。

> 对这个 bug 列出至少 3 条假设，按概率排序：

| # | 假设 | 概率 | 验证方法 | 验证结果 |
|----|------|------|---------|---------|
| 1 | 数据库连接池耗尽导致查询超时 | 40% | 查连接池监控 / 增加超时日志 | |
| 2 | 某个请求参数为 null 时 NPE | 30% | 加 null guard + 日志打印所有参数 | |
| 3 | 第三方 API 偶发超时未处理 | 20% | 加 try-catch + 超时配置 | |
| 4 | 缓存过期后雪崩 | 10% | 检查缓存 TTL 和预热逻辑 | |

> 这个 NPE 的 stack trace 在 JDK 内部，看不出来业务代码哪里出问题。
> 用 root-cause-tracing 从 Controller 入口追踪完整数据流。

root-cause-tracing:
  Controller.getUser(123)
    → UserService.findById(123)
      → UserRepository.findById(123)  ← 返回 Optional.empty()
        → UserService 没检查 Optional，直接 .get()
          → NullPointerException

> 这个 400 是偶发的，帮我 debug：
> 1. 先用 reproducible-test-case 写一个高并发测试，模拟 50 并发请求
> 2. 用 /loop 跑 20 次，收集所有失败
> 3. 分析失败请求的 pattern

> 用户管理页面：选择状态下拉 → 列表不刷新。
> 1. agent-browser: 打开页面，选择"激活"状态，截图
> 2. LSP: findReferences 找到 status filter 的所有引用
> 3. 检查 watch/watchEffect 的依赖是否正确