别再用 console.log 暴力调试了，试试这几招提升 JS 开发效率
console.log(data)。但实际操作中你会发现，一旦进入深层嵌套的对象数组，或者面对几十次循环的输出，控制台瞬间会被淹没。在成百上千行日志里翻找哪个变量对应哪个时间点，这种低效的调试方式在项目规模扩大后简直是噩梦。其实浏览器原生的调试工具链远比简单的打印日志强大，在实战中，我建议通过以下几个维度来替代传统的 log 模式。
首先是利用 debugger 关键字实现强制暂停。很多人习惯在怀疑有问题的代码块前后打印变量，但这种方式只能看到快照，看不到执行流。当你直接在代码中插入 debugger; 时，浏览器在执行到该行时会自动触发断点并暂停。此时你不需要在控制台盲目猜测，直接在 Sources 面板的 Scope 区域就能看到当前作用域下所有局部变量的实时状态。更重要的是，你可以通过 Step Over（单步跳过）或 Step Into（进入函数）来观察变量是如何在每一行代码中发生变化的，这比盯着控制台看打印结果要直观得多。
其次，针对数据的呈现方式进行优化。处理 API 返回的列表数据时，console.log 出来的数组需要一个个手动展开，极其低效。这时候 console.table 是更好的选择。当你传递一个对象数组给 console.table() 时，浏览器会将其渲染成一个标准的 HTML 表格，字段对齐，索引清晰。如果某个属性在 50 条数据中只有一条是 null，用表格形式一眼就能定位，而用 log 则需要手动展开 50 次。
如果你的业务流程涉及多个异步阶段，导致日志交织在一起，可以使用 console.group 和 console.groupEnd 将相关的日志打包。例如在处理“用户登录 → 权限校验 → 页面跳转”这一链路时，将这三个步骤的日志包裹在一个 group 中，控制台会生成一个可折叠的层级结构，这样你就能在不干扰其他日志的情况下，快速展开或关闭某个特定流程的执行记录。
另外，一个被很多开发者忽略的性能量化手段是 console.time。很多同学在分析接口响应时间或复杂循环性能时，习惯写 const start = new Date() 然后在结尾算差值，这不仅代码冗余，且精度不足。直接使用 console.time("label") 开始计时，在结束处调用 console.timeEnd("label")，浏览器会自动计算时间差并输出到控制台，精度达到毫秒级，非常适合用来快速排查某个异步请求是否出现了异常延迟。
最后，我想谈谈调试习惯。很多初学者在看到 Error Stack（错误堆栈）时习惯性地直接复制报错信息去搜索，其实堆栈信息里已经明确记录了具体的文件路径和行号，直接点击跳转比搜索快得多。同时，养成在部署前清理 console.log("HERE") 或 console.log("111") 这种临时标记的习惯，能避免生产环境控制台过于嘈杂，从而在面对真实线上问题时能更快速地捕捉到关键报错。
