JavaScript调试与测试技巧分享

JavaScript的调试与测试绝非项目收尾时的补救手段，而是贯穿编码全程的核心实践——从第一行代码起就需通过DevTools精准断点、结构化console输出（如group/table）、Jest规范异步与mock处理，并辅以source map和严格模式保障可追溯性与健壮性；真正高效的调试不是靠alert或盲目刷新，而是让代码从诞生之初就具备清晰的可观测性与可验证性。

JavaScript 调试和测试不是“先学语法再上手”，而是从第一行代码就开始介入的过程。你不需要等项目写完才开始调试，也不该靠 alert() 或反复刷新页面来验证逻辑。

在浏览器中用 DevTools 实时打断点调试

这是最常用也最容易被低估的调试方式。Chrome 和 Edge 的 DevTools 已经足够强大，关键在于怎么触发断点、怎么看上下文。

• 在源码面板（Sources）里点击行号左侧，设置断点；debugger 语句也能主动触发断点，但上线前必须删掉
• 断点停住后，优先看右侧面板的 Scope（变量作用域）、Call Stack（调用栈），而不是盲目 console.log
• 鼠标悬停在变量上可直接查看当前值；右键变量名可“Watch”它，方便持续追踪变化
• 避免在异步回调（如 setTimeout、fetch.then）里打错位置的断点——它们可能根本不会触发，因为代码没执行到那一步

用 console.group 和 console.table 提升日志可读性

单纯用 console.log() 输出对象或嵌套数据，容易淹没在一堆展开/折叠操作里。结构化输出能快速定位问题。

• console.group('API Response') + console.groupEnd() 可折叠一组日志，适合分阶段输出
• 对数组或对象列表，直接用 console.table(data)，比 console.log 更直观，尤其适合检查字段缺失或类型异常
• console.warn() 和 console.error() 不仅颜色不同，还会被 DevTools 的过滤器单独归类，方便筛选
• 别在循环里无条件打 console.log(i) —— 加个条件，比如 i % 10 === 0，否则卡死页面

用 Jest 写单元测试时避开常见陷阱

Jest 是目前最主流的 JS 测试工具，但它默认行为和实际项目需求之间有几个关键缝隙。

• 异步测试必须显式处理：用 async/await + expect(...).resolves，或者 return promise + .then，否则测试会提前通过
• 模拟函数（jest.fn()）要记得清理：在 beforeEach 里重置，或用 mockClear()，否则上次调用的返回值或调用次数会影响新测试
• DOM 相关测试别直接依赖真实浏览器；Jest 默认用 jsdom，它不支持 localStorage 全部 API，需要手动 mock：global.localStorage = { getItem: jest.fn() }
• 测试文件名必须是 *.test.js 或 *.spec.js，且放在项目根目录或 __tests__ 文件夹下，否则 Jest 找不到

本地启动服务时启用 source map 和严格模式

压缩后的代码出错，堆栈全是 bundle.js:12345，根本没法定位。source map 是调试的基础保障，而严格模式能提前暴露隐性错误。

• Webpack/Vite 等构建工具默认开启 devtool: 'source-map'（开发环境），但生产环境打包时要确认是否误带了 sourceMap: true 配置，否则泄露源码
• 在脚本顶部加 'use strict';，能让 JS 引擎拒绝执行某些危险操作，比如给未声明变量赋值（foo = 1 会报错，而不是创建全局变量）
• ESLint 配置里启用 strict 规则，比手动加 'use strict' 更可靠，还能统一团队风格
• Node.js 运行时可通过 node --inspect-brk script.js 启动调试，然后在 Chrome 地址栏输入 chrome://inspect 连接，适合调试 CLI 工具或服务端逻辑

真正卡住人的，往往不是不会用断点，而是没意识到某个异步操作根本没进回调；也不是没写测试，而是 mock 数据和真实响应结构不一致导致断言永远失败。调试和测试的有效性，取决于你是否在写代码的同时就在设计它的可观测性。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JavaScript调试与测试技巧分享》文章吧，也可关注golang学习网公众号了解相关技术文章。