刚入行那会儿，我为了查一个按钮点击没反应的问题，愣是在代码里翻了两个小时。最后发现只是事件绑定写成了 onclick 而不是 onClick。这种低级错误谁没犯过？前端开发最不缺的就是“看起来没问题，但就是不工作”的场景。时间久了，慢慢攒了些实用的调试技巧，今天拿出来聊聊。
善用浏览器开发者工具的断点
很多人只把控制台当 console.log 的输出地，其实它的调试功能强得多。比如在 Chrome DevTools 里，直接点击行号就能加断点。当你触发某个操作时，代码会停在那里，你可以一步步执行，看变量怎么变。
举个例子，有个表单提交后数据总对不上，你可以在处理函数的第一行设个断点，然后观察传进来的值是不是预期的。这时候鼠标悬停在变量上就能看到内容，比 console.log 干净多了。
别让 console 淹没你的日志
满屏都是 console.log('test') 的时候，根本找不到重点。试试用带标签的方式输出：
console.log('[用户登录] 返回数据:', userData);
console.warn('[权限检查] 用户未授权');
console.error('[API 请求失败] 接口地址:', url);
这样一眼就能分清哪条日志来自哪个模块。警告和错误也用不同颜色标出来，排查问题更快。
网络请求卡住了？看 Network 面板
接口返回 401 但前端没提示，这种情况太常见。打开 Network 面板，刷新页面，所有请求一目了然。点击具体请求，可以看到请求头、响应体、状态码，甚至耗时分布。
有一次线上环境图片加载不出来，本地却正常。抓包一看，原来是 CDN 地址拼错了协议，HTTP 被强制跳转 HTTPS 后路径丢了。这种问题光看代码很难发现，Network 面板直接暴露了重定向过程。
样式错乱不用猜，Elements 面板动手改
布局突然塌了，可能是 margin 把别人挤开了，也可能是 display 属性被覆盖。Elements 面板允许你实时修改 DOM 和 CSS。勾选或取消某个样式，效果立刻可见。
遇到移动端适配问题，我习惯先在 Elements 里把元素的 border 加上，看看实际占位是不是符合预期。很多时候所谓的“空白”其实是 padding 或者父容器 overflow:hidden 切掉了内容。
巧用 debugger 语句
除了手动打断点，还可以在代码里写 debugger;。只要这行被执行，浏览器就会自动暂停。
function calculatePrice(items) {
if (!items || items.length === 0) {
debugger;
return 0;
}
// ...
}
这个方法适合复现条件较复杂的场景。比如只有特定用户登录后才会进入的逻辑分支，靠手动触发太麻烦，加个 debugger 更高效。
模拟弱网环境测试体验
公司 Wi-Fi 很快，但用户可能在地铁里刷你的页面。DevTools 的 Network Throttling 功能可以模拟慢速网络，比如 “Slow 3G”。开启后你会发现，原来那个“瞬间完成”的加载动画其实要等七八秒。
这时候就能顺手加上骨架屏或者进度条，而不是等到用户投诉才想起来优化。
手机端调试也不难
真机调试不用非得装一堆工具。Chrome 支持 USB 连接安卓设备远程调试。连上后在电脑端就能查看手机浏览器的 console 和 DOM 结构。
苹果用户可以用 Safari 的 Web Inspector。打开手机设置里的“Web 检查器”，再在 Mac 上的 Safari 开发菜单里选中对应页面，一样能调试。
利用 localStorage 快速切换环境
开发时经常要在测试环境和预发布之间切换 API 地址。与其每次改代码，不如读取 localStorage 的配置。
// 开发时临时使用
localStorage.setItem('API_BASE', 'https://staging.api.com');
// 请求时判断
const baseUrl = localStorage.getItem('API_BASE') || 'https://api.example.com';
上线前删掉这一句就行，不影响正式逻辑。临时调试特别方便。