浏览器开发者工具是JavaScript调试默认搭档，通过F12打开；可用debugger语句或Sources面板手动设断点，配合条件断点、属性修改断点、sourcemap及Network面板协同定位问题。
JavaScript 调试不靠猜，靠浏览器开发者工具——它不是“附加功能”，而是你写 JS 时默认的搭档。只要打开 F12 或 Ctrl+Shift+I（Mac 是 Cmd+Option+I），你就已经站在调试入口了。
怎么在代码里设断点并暂停执行
最直接的方式是用 debugger 语句，它会在运行到那一行时自动触发断点（前提是开发者工具开着）；但更常用、更可控的是在 Sources 面板里点击行号左侧的蓝点手动加断点。
-
debugger在生产环境要删掉或用构建工具剔除，否则用户也会停住 - 动态生成的代码（比如通过
eval或模板字符串拼出的函数）可能不会出现在 Sources 列表里，得靠debugger或 “Event Listener Breakpoints” 补救 - 条件断点右键蓝点可设置，比如输入
userId === 123，只在特定数据下暂停
console.log 够用吗？什么时候必须用断点
console.log 快，但信息有限：看不到作用域内所有变量实时值，没法单步进函数内部，也不能修改变量后继续跑。遇到异步链（Promise、async/await）、闭包变量变化、或某次循环中间出错时，console.log 往往只能告诉你“错了”，而断点能告诉你“在哪错、为什么错、上下文是什么”。
- 在
then回调里打console.log可能输出undefined，但断点进去看this或局部变量一目了然 - 想观察某个对象被谁改过？右键该对象属性 → “Break on property modification”，比埋一堆日志高效得多
-
console.table()和console.group()可以补足日志可读性，但替代不了执行流控制
Network 面板怎么看接口问题是不是 JS 引起的
很多“JS 报错”其实是接口返回了非预期数据（比如 500 响应体是 HTML 而不是 JSON），或者 CORS 被拦导致 fetch 拒绝返回。Network 面板能确认请求是否发出、状态码是否正常、响应头有没有 Content-Type: application/json、响应体是否真为 JSON。
立即学习“Java免费学习笔记（深入）”；
- 勾选 “Preserve log”，防止页面跳转后清空请求记录
- 右键某条请求 → “Copy” → “Copy as fetch”，直接拿到可复现的调用代码，省去手写测试
- 禁用缓存（Disable cache）开关要打开，否则可能误判 JS 逻辑——你以为改了代码，其实浏览器还在用旧响应
Sources 面板里怎么查压缩后的代码问题
线上代码基本都经过打包压缩，Sources 显示的是 bundle.js 这类文件，变量名全变成 r、n，根本看不懂。这时得依赖 sourcemap：
- 确保构建时生成了
.map文件，且部署时一同上传，并在 JS 文件末尾有//# sourceMappingURL=bundle.js.map - Chrome 默认自动加载 sourcemap，加载成功后左上角会显示原始文件路径（如
src/utils/api.ts），断点也能打在源码行上 - 如果没反应，检查 Network 面板里
bundle.js.map是否 404，或 DevTools 设置里 “Enable JavaScript source maps” 是否开启
真正卡住人的往往不是“找不到工具”，而是没意识到：Network 里看到 200 不代表数据可用，Sources 里没报错不等于逻辑正确，console 里打印出对象也不代表它没被后续代码覆盖。调试的本质，是缩小「预期」和「实际」之间的落差，而浏览器工具只是把落差摊开给你看的那面镜子。
