17370845950

JavaScript调试应优先使用DevTools断点、作用域和调用栈，3分钟内可定位多数逻辑错误；断点需设在变量已赋值未被误改处，异步回调须单独设置，配合Watch/Scope面板、Network与Console协同分析，并善用VS Code调试插件。

JavaScript 调试不是靠 console.log 硬刷，而是用好浏览器 DevTools 的断点、作用域和调用栈——绝大多数逻辑错误 3 分钟内就能定位。

在 Chrome DevTools 里下断点比 console.log 快得多

手动插入 debugger 语句或直接在 Sources 面板点击行号设断点，都能暂停执行。关键在于：断点要下在「变量已赋值但还没被误改」的位置，而不是函数开头。

• 函数参数刚进来时下断点，能立刻看到传入值是否符合预期
• 异步回调里（比如 then() 或 setTimeout）必须单独设断点，debugger 不会自动跳进回调
• 条件断点（右键行号 → “Edit breakpoint”）适合排查循环中某次迭代出错，比如 i === 42

Watch 和 Scope 面板比反复 console.log 变量更可靠

控制台里敲 console.log(a, b, c) 容易漏掉嵌套属性或引用变化；而 Watch 面板能实时跟踪表达式，Scope 面板则原生展示当前函数闭包里的所有变量及其值。

• Watch 支持输入任意表达式，比如 user.profile?.permissions?.length，不用怕报错
• 如果看到某个对象值显示为 VM123 或 Object 后没展开箭头，说明它被优化掉了（常见于未使用的局部变量），加个 debugger 或访问一下该属性可强制保留
• 鼠标悬停在代码变量上也能临时查看值，但只适用于简单类型，复杂对象仍要靠 Scope

Network 和 Console 面板协同查接口和报错源头

前端问题常卡在“数据没来”或“来了但结构不对”。这时候不能只盯着 JS 逻辑，要联动 Network 查响应体，再回溯到 Console 看报错堆栈。

• Console 报 Cannot read property 'name' of undefined？先看 Network 中对应请求的 Response 是否为空或字段缺失
• 勾选 Network 面板的 “Preserve log”，避免页面跳转后丢失请求记录
• 在 Console 输入 $0 可获取 Elements 面板中最后选中的 DOM 节点，配合 console.dir($0) 查事件监听器或数据属性

VS Code + Chrome Debugger 插件适合调试本地开发服务

当项目启动在 localhost:3000 或使用 Vite/Next.js 时，直接在 VS Code 里打断点并单步调试，比切到浏览器 Sources 更顺手。

• 需安装官方插件 Debugger for Chrome 或新版统一的 JavaScript Debugger
• launch.json 中配置 url 和 webRoot 是关键，否则断点不命中；webRoot 通常设为 "${workspaceFolder}/src"
• 遇到 Unbound breakpoint 提示，大概率是 sourcemap 路径不对，检查构建工具是否生成了 .map 文件并正确映射

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-chrome",
      "request": "launch",
      "name": "Launch Chrome",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}/src",
      "sourceMapPathOverrides": {
        "webpack:///src/*": "${webRoot}/*"
      }
    }
  ]
}

真正卡住人的往往不是不会用工具，而是断点下在了错误的执行时机，或者忽略了异步上下文切换导致的变量失效——多看一眼 Call Stack 面板里的函数层级，比重读十遍代码更快。