1. 先看日志，别急着打断点
遇到问题第一反应应该是翻日志（应用日志、系统日志、浏览器控制台），而不是直接上 debugger。90% 的问题在日志里都有线索，特别是 "ERROR"、"Exception"、"Failed" 附近的上下文。养成tail -f 开着日志窗口的习惯，比事后翻查效率高。
2. 二分法缩小范围
如果不知道哪段代码出了问题，用注释或条件判断把代码切成两半，看问题还在不在。重复这个过程，通常 3-4 次就能定位到具体函数。Git 的 git bisect 也是这个原理，适合排查"昨天还好好的"这类回归 bug。
3. 最小复现
把复杂的业务场景剥到最简：新建一个空文件/空项目，只保留核心逻辑，看 bug 是否还在。如果消失了，逐个加回依赖；如果还在，问题就在这几行代码里。这招对付"环境相关"的 bug 特别有效。
4. 对比法
- 好机器 vs 坏机器：对比配置文件、依赖版本、环境变量
- 老版本 vs 新版本：
git diff看最近改了什么 - 本地 vs 线上：往往是数据差异或并发场景不同
5. 用 print 别害羞
别以为用 print 调试很 low。对于异步、多线程或分布式场景，print 比 IDE 的 debugger 更稳定，不会因为断点暂停导致时序错乱。关键是打印时要带上线程 ID 和时间戳。
6. 抓包看真相
前后端扯皮时，用 Chrome DevTools、Wireshark 或 tcpdump 抓包，看实际发出去的数据是什么。很多时候"我传了"和"我收到了"之间差了一个字段大小写或编码问题。
7. Rubber Duck（小黄鸭调试法）
对着同事、 teddy bear 或聊天窗口，把问题逻辑从头到尾讲一遍。往往讲到一半你自己就发现了漏洞——因为表达思路比单纯想更容易暴露逻辑断层。
8. 改一行测一行
不要一次改 10 处代码然后祈祷。每次只改一处，立即验证。如果问题解决了，别急着提交，先 revert 确认 bug 能复现，再应用修改，确保真的是这个改动修好的，而不是巧合。
9. 善用异常断点
在 IDE 里设置 "Break on Exception"（特别是捕获所有未处理的异常），让程序在抛出异常的第一现场停住，而不是被外层 try-catch 吞掉后到处找日志。
10. 知道何时停
如果卡了超过 30 分钟还没头绪，立刻去倒水、上厕所或散步。大脑陷入"确认偏误"时，继续钻牛角尖只会浪费时间。回来后再从第 1 条开始过一遍。