JavaScript调试应善用DevTools断点与执行流控制而非仅靠console.log；优先使用debugger语句、合理设置异步断点、启用Source Map、掌握console高级技巧及内存泄漏排查方法。
JavaScript 调试不是靠 console.log 硬刷，而是用好浏览器 DevTools 的断点与执行流控制——否则你永远在猜“到底执行到哪了”。
如何在 Chrome 中设置有效断点
直接在 Sources 面板点击行号左侧设断点，但容易失效：压缩代码、动态加载、Source Map 未启用都会让断点偏移或不触发。
- 优先用
debugger语句，在代码逻辑关键处手动插入（它会在启用 DevTools 时生效，禁用时自动忽略） - 避免在异步回调开头盲目打点；改用
async/await后在await行设断点，能真正暂停执行流 - 对第三方库调试，先确认已加载 Source Map（Network 面板查
.map文件是否 200），再在 Overrides 中映射本地源码
console 不只是打印：高级日志技巧
console.log 本身有隐藏能力，但多数人只用它输出字符串。
- 用
console.table(data)查看数组或对象结构，比展开嵌套更直观 -
console.group('API')+console.groupEnd()折叠日志块，适合追踪一次请求的完整链路 -
console.time('fetch')/console.timeEnd('fetch')测量某段执行耗时，比手动记时间戳准得多 - 条件日志：
console.assert(condition, '错误：用户未登录')，只在 condition 为 false 时输出
为什么 step over 有时跳进源码、有时跳过？
这取决于当前行是否“有可执行逻辑”，而不仅是有没有函数调用。Chrome 的单步行为受 sourcemap、内联函数、编译器优化影响很大。
立即学习“Java免费学习笔记（深入）”；
-
Step Over (F10)：跳过当前行，但如果该行是 Promise.then() 或 async 函数调用，实际会进入其内部——因为 JS 引擎把它们视为“可暂停点” - 想跳过所有异步逻辑？用
Step Out (Shift+F11)快速跳出当前函数，再配合 Call Stack 看清上下文 - 遇到 minified 代码卡住，右上角点击
{}格式化按钮，再结合Ctrl+Shift+O快速跳转函数定义
常见调试盲区：事件监听器和内存泄漏
很多问题不报错、不阻塞，但页面变卡、响应延迟——这类问题几乎从不触发断点，得换思路。
- 在 Elements 面板选中元素 → 右侧 Event Listeners 标签，查看绑定的
click、scroll等监听器，点右侧文件链接可直接跳转源码 - Memory 面板录制 Allocation instrumentation on timeline，滚动或操作后观察“蓝色小方块”是否持续增长，那是新对象不断被创建的信号
- 怀疑闭包导致内存泄漏？用
console.dir(element)查看 DOM 元素引用关系，再配合 Heap Snapshot 对比前后差异
真正卡住你的往往不是语法错误，而是执行时机、作用域链、原型继承这些看不见的链路——调试器不是用来“看变量值”的，是用来验证你对运行时行为的假设是否成立的。
