10 篇博文 含有标签「调试」

最尴尬的一次排查，不是没日志，而是四拨人都拿着“自己的那条 id”在说话。前端同学贴了一个 sessionId，BFF 说自己只有 requestId，工作流平台那边只认 runId，到了工具服务层又冒出一个没人见过的 trace。会议开了十几分钟，大家连“我们查的是不是同一次请求”都还没对齐。

React 18 上线后，不少项目第一次在开发环境里看到副作用执行两次，直觉都会觉得“框架是不是出问题了”。但我自己的经验是，StrictMode 暴露的往往不是框架 bug，而是我们本来就没处理好的副作用和初始化假设。

webpack 配 source map 时，很多人最开始只有一个判断标准：能不能在浏览器里看到原始源码。可项目一大以后，你会发现 source map 其实牵连了很多事，构建速度、调试精度、错误定位、产物暴露范围，全都和它有关。选型如果只看“调试爽不爽”，很容易在发布阶段踩坑。

Java 集合遍历删除这个问题，很多人都知道有坑。
可真正麻烦的地方在于，它不是每次都立刻用最醒目的方式出错。有些代码在某个数据量、某种路径下能跑，看起来像是可用的，结果一换场景就开始报错或者漏删，这种“看起来能跑”的状态反而最危险。

Java 项目里很容易出现一种“看上去很稳”的异常处理：每一层都在 catch，每一层都在包一层自己的提示，最后用户确实看不到原始异常了，但开发排查时也很难再看到真正的现场。
2017 年我在处理一些线上问题时，对这一点的体会越来越深。

页面一旦出现“点击没反应”或者“滚动明显发卡”，很多人会笼统地说这是性能问题。但性能问题如果只停在这个词上，其实没有任何帮助。对前端来说，更实用的还是先把问题拆开：是逻辑没走到，还是逻辑走到了但执行得太重。

2013 年前端开发已经越来越离不开浏览器开发者工具了。页面一出问题，如果不会用 DevTools，很多排查只能靠猜。

样式问题最容易让人陷入一种低效循环：改一处 CSS，刷新页面，看不对，再回去改下一处。尤其是接手别人留下来的页面时，选择器层级多、覆盖关系杂，如果只在源码里猜，很快就会迷路。

浏览器里出现白屏、按钮没反应、数据不显示时，很多人的第一反应还是回编辑器里盯代码。但真到项目节奏快的时候，这种做法经常会让人越看越散。Chrome DevTools 真正有用的地方，是它能先帮你把问题范围收住。

2013 年刚开始用 Node.js 写小服务时，很多项目规模不大，大家对日志的预期也很简单：出问题时能在控制台看到几行输出就行。可我后来越写越觉得，哪怕暂时还没有完整日志系统，只是写到控制台，日志也应该先有最基本的格式感。