上周三凌晨两点，代码检测我盯着屏幕上跳动的代码检测红色波浪线，第17次修改同一个函数。代码检测那是代码检测个简单的日期格式化工具，逻辑不到十行，代码检测但SonarQube死活判定它存在“认知复杂度过高”的代码检测问题。改到第9版时，代码检测我把if-else拆成了三个独立方法，代码检测工具终于绿了——可代码行数从8行变成了41行。代码检测那一刻我特别想砸键盘。代码检测

这就是代码检测代码检测的日常。静态分析工具像一位极其较真但不太懂变通的代码检测老师傅，拿着游标卡尺量你每一行代码，代码检测差0.01毫米都要打回重做。代码检测它不管你半夜三点脑子是代码检测否清醒，也不管业务需求明天就要上线。它只认规则。

我见过最离谱的一次，团队里新来的小伙子提交了一段完美的防抖函数。setTimeout加clearTimeout，经典实现，没有任何问题。但ESLint的no-unused-vars规则把timer变量标记为未使用——因为它在闭包里被引用，而规则没配置闭包上下文。小伙子折腾了四十分钟，最后加了一行// eslint-disable-next-line。注释比代码还长。

但话说回来，没有这些工具，代码库早就烂成泥了。三年前我接手过一个老项目，git blame显示某个文件最后一次修改是2016年。打开一看，三千多行，全局变量满天飞，函数嵌套七层，var和let混用。我当时就想，如果这项目从第一天就挂上ESLint和Prettier，至少能少一半的屎山。工具确实烦，但它是那种“烦得有用”的烦。就像牙医的钻头，嗡嗡响得让人头皮发麻，可没它你牙就烂穿了。

关键是怎么用。我现在的习惯是分三层：编辑器里实时跑ESLint，只报错不自动修，让我自己决定；提交前跑Prettier和Stylelint，格式问题机器说了算，我不跟它争；CI流水线上跑SonarQube和单元测试覆盖率，低于80%直接卡住不让合并。这套组合拳打下来，代码评审时大家终于不用再吵“这里该不该换行”这种破事，能专心聊业务逻辑了。

有个细节挺有意思。我们团队有个老哥，写代码从来不用分号，说“JavaScript会自动插入，写分号是脱裤子放屁”。ESLint的semi规则默认要求分号，他每次提交都要手动关掉。后来我们干脆把规则改成["error", "never"]，全团队都不用分号了。工具是死的，人是活的。规则应该服务于团队习惯，而不是反过来让团队跪着适应规则。当然，前提是团队得先达成一致——别今天你加分号明天我删分号，那Git diff里全是噪音。

说到底，代码检测不是找茬，是给代码库装了一套免疫系统。它会在你手滑写出==而不是===的时候亮红灯，会在你复制粘贴忘记改变量名的时候发出警告，会在你写了个永远不会执行的else分支时默默标黄。这些破事人眼很容易漏，机器一次都不会漏。

但别指望它能帮你写出好代码。工具能告诉你“这行有分号问题”，但它不知道你为什么要写这行。上周我重构一个支付回调模块，SonarQube提示“方法过长”，建议拆分。我拆了，结果拆出来的三个方法互相调用，参数传了七八个，比原来还难读。最后我把它们合回去了，加了一行// NOSONAR。工具闭嘴了，代码反而清爽了。

所以我的态度很简单：让工具管格式，让人管逻辑。该关的规则就关，该加的注释就加。别为了讨好检测工具把代码写成四不像——那才是真正的技术债。凌晨两点改代码已经够苦了，别再让一个不懂业务的静态分析器骑在你头上。