JavaScript调试测试应从第一行代码开始，用DevTools断点、console.group/table等提升可观测性，Jest需正确处理异步和mock，source map与严格模式保障调试质量。
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 测试工具，但它默认行为和实际项目需求之间有几个关键缝隙。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 异步测试必须显式处理：用
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 数据和真实响应结构不一致导致断言永远失败。调试和测试的有效性，取决于你是否在写代码的同时就在设计它的可观测性。
