断点调试技巧：让代码问题无处藏身
写代码最怕什么？不是写不出功能，而是功能跑不起来。明明逻辑没问题，结果就是不对。这时候，别急着删代码重写，试试断点调试——它就像给程序装上慢动作回放，让你一眼看出哪里出了岔子。
在合适的位置下断点
很多人一上来就在第一行打个断点，然后一步步往下走，走到崩溃。其实断点要打得聪明。比如你发现某个函数返回值总是错的，那就直接在函数入口处设断点，而不是从头开始。
举个例子，你在写一个计算折扣价格的函数：
function calculatePrice(original, discountRate) {
let discount = original * discountRate;
let final = original - discount;
return final;
}如果发现final算出来不对，别从original传入就开始跟，直接在let final = original - discount;这一行加断点，看看两个变量的值是不是如预期。
利用条件断点减少干扰
循环里出问题怎么办？比如一个数组处理，第100次循环才出错。难道要手动点99次继续？当然不用。现代编辑器都支持条件断点——只有满足条件时才会暂停。
在 Chrome DevTools 或 VS Code 中，右键断点可以设置条件。比如只在i === 99时中断，直接跳到问题现场。
查看调用栈定位源头
有时候断点停了，你看到当前变量错了，但不知道是谁传进来错数据的。这时候看“调用栈”（Call Stack）就很有用。它像一张回溯地图，告诉你这个函数是怎么被一层层调过来的。
比如一个saveUser函数收到的用户名是undefined，你在函数开头断住，调用栈会显示是来自handleSubmit → validateForm → onClick，顺着往上查，很快就能发现是表单没取对值。
修改变量值实时测试
断点停下来后，别忘了你可以“动手改”。比如你怀疑是某个判断条件太严格，可以直接在调试面板里把isValid从false改成true，然后继续运行，看程序行为是否恢复正常。这比改代码、保存、刷新、再操作快多了。
别忽视控制台联动
断点暂停时，调试器的控制台依然可用。你可以手动执行表达式，比如输入userList.filter(u => u.age > 30)看看结果，或者调用一个工具函数验证逻辑。这相当于在程序暂停时，还能和它对话。
避开常见坑
有些人设了断点却没反应，往往是源码映射没配好，特别是在用 Webpack 或 Babel 的项目中。确保生成了 sourcemap，并在调试器中正确加载。
还有一种情况：异步代码断不住。比如setTimeout或Promise.then里的逻辑。这时可以在回调函数第一行手动加debugger;语句，强制中断：
setTimeout(() => {
debugger;
console.log('这里会暂停');
}, 1000);这招在生产环境排查问题时尤其管用，不用依赖外部工具也能临时介入。