断点调试本质是浏览器通过CDP协议向JS引擎动态注入暂停钩子，依赖source map映射源码与执行位置，仅挂起JS主线程而非整个页面，并实时引用内存中变量对象。
断点调试不是“让代码停下来”这么简单，它的底层原理，其实是一场浏览器和 JavaScript 引擎之间的实时协作——就像交警临时拦下一辆车，不是为了扣分，而是要检查它刚从哪来、正往哪去、后备箱里装了什么。
引擎在执行，浏览器在监听
JavaScript 代码最终由 V8（Chrome/Edge）、SpiderMonkey（Firefox）等引擎执行。这些引擎在运行时会持续向开发者工具（DevTools）暴露一个叫 Chrome DevTools Protocol（CDP） 的通信通道。你点一下行号加断点，浏览器不是改了你的源码，而是通过 CDP 向引擎发了一条指令：“请在执行到第 42 行前，主动暂停，并把当前上下文快照传给我”。引擎收到后，会在对应字节码位置插入一个“暂停钩子”，等真正执行到那里，立刻中断并回传调用栈、作用域、寄存器状态等数据。
断点不是“贴在源码上”，而是“映射到真实执行位置”
你看到的 JS 文件，往往不是原始执行的代码：可能是压缩过的、经过 Babel 转译的、或者由 Webpack 打包生成的 bundle.js。这时候，浏览器靠 source map 文件把压缩后代码的某一行，精准还原回原始源码的行列号。没有 source map，断点可能打偏、变量名显示为 t/n/r；有了它，你才能在未压缩的 .ts 或 .jsx 文件里打断点，却让引擎在 bundle.js 里准确停下——这背后是编译时生成的坐标映射表在默默工作。
暂停 ≠ 冻结整个页面，只是冻结 JS 主线程
断点命中后，页面看起来“卡住”了，但其实只是 JS 主线程被挂起。DOM 渲染、CSS 动画、网络请求（如 fetch 已发出的响应）、Web Worker 里的代码仍在运行。这也是为什么你在断点里看不到刚发出去的 XHR 响应（它还没回来），但能看到 setTimeout 的计时器还在悄悄走——因为事件循环（Event Loop）没停，只是 JS 调用栈被按了暂停键。
你看到的变量值，是“此刻快照”，不是静态快照
Scope 面板里显示的变量，不是复制了一份值，而是 DevTools 持有对内存中真实对象的引用。所以当你展开一个对象看属性，再在控制台输入 obj.name = "new"，Scope 里那个 obj 的 name 会立刻变——这不是 Bug，是它真正在看同一块内存。这也是为什么深查对象要用 JSON.stringify(obj, null, 2)，否则容易被后续修改误导。
