发现问题是调试的第一步
写代码的人，谁还没见过程序突然崩溃、页面白屏或者按钮点了没反应？这些问题往往就是调试的起点。比如你开发一个购物车功能，用户点击结算却跳转到了首页，这时候就得开始查问题出在哪。
别急着改代码，先确认现象是否稳定复现。有时候是网络延迟导致的假死，有时候是缓存数据错乱。把操作步骤记下来，能稳定重现才好下手。
定位错误发生的位置
现代开发工具都挺给力，浏览器按 F12 就能看到报错信息，IDE 里也能看到堆栈跟踪。比如控制台打出 TypeError: Cannot read property 'id' of undefined，那基本可以确定是在访问一个未定义对象的 id 属性。
这时候可以在可疑的地方加断点，或者用 console.log 输出变量值。虽然老派，但特别实在。比如在循环中间打印一下当前项，看看是不是某条数据格式不对导致后续处理出错。
缩小问题范围
如果整个模块都跑不起来，不要从头读到尾。试着把功能拆开看，比如后端接口返回的数据对不对，前端拿到数据后渲染有没有问题。可以模拟一个固定数据直接传给页面，绕过请求环节，快速判断是通信问题还是逻辑问题。
举个例子，列表页一直空白，你可以手动写死一组数据喂给渲染函数。如果这时候能正常显示，说明问题出在数据获取阶段；如果还是不行，那就是渲染逻辑本身有 bug。
修改并验证修复效果
找到问题根源后，改代码要小步快走。比如发现是因为某个字段没做空值判断，那就加上条件分支：
if (user && user.id) {
console.log(user.id);
} else {
console.log('user is not defined');
}改完之后不是万事大吉，得重新跑一遍之前的测试流程，确保问题真解决了，而且没引入新问题。最好还能补个单元测试，防止以后被人一不小心又改回去。
记录调试过程很有必要
有些问题几年都不见得出现一次，比如时区转换出错、浮点数精度丢失。解决完了顺手记两笔，下次遇到类似情况翻翻笔记，省得再折腾半天。团队协作时更应该共享这些经验，避免同一类坑被反复踩。
调试不是炫技，也不是越复杂越好。目标是让程序恢复正常运行，过程清晰、改动稳妥，比啥都强。