断点调试不是大神专属
刚入门前端那会儿，一看到控制台红字就慌，改代码全靠猜。后来发现，断点调试才是定位问题的“显微镜”。比如页面按钮点了没反应，与其反复刷新试错，不如在点击事件对应的函数里加个断点，看看执行到哪一步卡住了。
浏览器开发者工具中设置断点
Chrome 的 DevTools 是最常用的调试环境。打开 Sources 面板，在左侧文件树中找到你的 JavaScript 文件，点击行号就能设断点。刷新页面后，代码运行到该行会自动暂停，右侧 Scope 面板会显示当前变量值，方便你逐行排查逻辑错误。
也可以使用 debugger; 语句在代码中手动插入断点：
function calculateTotal(price, tax) {
debugger;
return price + tax;
}当这行代码被执行时，浏览器会自动中断，适合临时调试某一段逻辑。
条件断点避免频繁中断
循环里打普通断点？小心被卡到怀疑人生。右键行号选择“Add conditional breakpoint”，输入条件表达式，比如 i === 99，只有满足条件时才会暂停。处理大量数据或分页加载时特别管用。
监控特定变量的变化
想追踪某个变量是怎么被改掉的？在 Scope 面板中右键变量名，选择“Break on property modification”（针对对象属性）或使用 DOM 断点配合数据变化监听。比如一个表单提交前的数据被莫名清空，用这个方法能快速定位是哪个函数动了手脚。
利用调用栈理清执行路径
断点触发后，Call Stack 面板会显示函数调用顺序。点击任意一层，可以跳转到对应代码位置。曾遇到过一个 bug，是第三方库回调里改了全局状态，通过调用栈一眼就看出是谁触发的源头。
网络请求也能打断点
XHR/Fetch 请求出问题，别只看返回结果。在 Network 面板勾选“Preserve log”，然后在请求发出前设断点，观察请求头、参数是否正确生成。有时候接口报 400，其实是前端拼错了字段名，断点一打，立马现形。
调试压缩后的代码怎么办
生产环境的 JS 通常被压缩成一行，直接看几乎不可能。点击 Sources 面板底部的 “{}” 按钮（Pretty Print），代码会格式化成可读结构，虽然变量名还是 a、b、c，但至少能跟着流程走一遍。
再配合鼠标悬停查看变量值，或者在 Console 中打印中间结果，哪怕看不懂全部逻辑，也能揪出异常节点。