chrome DevTools断点调试最直接有效，需结合debugger语句、行号断点与条件断点；善用console.group、table、格式化及标签过滤；错误须用console.Error输出完整对象；VS Code调试需正确配置sourceMaps和webRoot。
chrome devtools 断点调试最直接有效
绝大多数前端问题，用 Chrome 自带的 DevTools 就能快速定位。关键不是打开控制台，而是会设断点：debugger 语句、行号点击、条件断点三者配合才高效。
-
debugger放在可疑逻辑前，刷新后自动停住；注意上线前务必删掉，否则用户也会卡住 - 在 Sources 面板里点击行号设断点，右键可转为「条件断点」——比如只在
user.id === 123时触发 - 函数内部变量悬停可看实时值，但注意闭包变量可能显示
not available，此时需在作用域链中找对应上下文 - 不要依赖「Step over」一路走到底，遇到循环或深层调用，优先用「continue to here」跳到目标行
console.log 不只是打印，要善用分组和格式化
盲目刷 console.log 容易淹没关键信息，反而拖慢排查节奏。真正有用的写法是让输出自带结构和语义。
- 用
console.group('API')+console.groupEnd()折叠日志块，尤其适合请求链路追踪 -
console.table(data)查看数组或对象列表，比console.log更直观，支持按列排序 - 格式化占位符：
console.log('User %s, age %d', name, age)比拼字符串更安全，避免undefined拼接出"nameundefined" - 加标签过滤：
console.log('%cauth', 'color: red', user)，再在控制台 Filter 输入auth即可筛选
catch 错误时别只打 err.message
很多开发者在 try/catch 里只打印 err.message，结果丢失堆栈和上下文，根本看不出错在哪一行、什么条件下触发。
- 始终用
console.error(err)输出完整错误对象，DevTools 会自动展开堆栈，点击就能跳转源码 - 异步错误（如
fetch后的.catch()）容易漏处理，建议统一加个兜底：window.addEventListener('unhandledrejection', e => console.error(e.reason)) - 自定义错误时，继承
Error并设置name和cause（如new ApiError('timeout', { cause: originalErr })），方便后续分类统计
VS Code 调试配置常被忽略的细节
本地开发时 VS Code 的 debugger 功能很强，但多数人没配对 launch.json，导致断点不生效或路径映射失败。
立即学习“Java免费学习笔记（深入）”；
- 确保
sourceMaps为true，且构建工具（如 webpack/vite）也启用了 sourcemap 输出 - 关键字段
webRoot必须指向实际运行时的根目录（通常是${workspaceFolder}），否则断点找不到源码位置 - 如果用 Live Server 插件启动页面，
url要填http://127.0.0.1:5500/这类真实地址，不能写file:// - 调试 node.js 脚本时，
runtimeExecutable显式指定node路径，避免多版本冲突导致Cannot find module
调试 javaScript 最难的不是工具不会用，而是判断该在哪设断点、该信哪条日志、该怀疑哪一层环境。浏览器里看到的 undefined，可能是 typescript 类型擦除后的结果，也可能是 Proxy 拦截后没返回值——得结合上下文才能下结论。