晚上快九点了吧，我坐地铁回家，一个同事发了一句——“Bug率降一半，全靠这几个IDEA插件撑着”。我当时一愣，心想这不是玄学吧？结果点开他发的图一看，嗯……还真有点门道。那晚我边回家边琢磨，第二天我就全装上试了试，现在用下来，真心觉得，哪怕你不是代码洁癖，也该试试这几款。

代码界的“扫地僧”：Alibaba Java Coding Guidelines

我先说最有用的，也是我觉得最“佛系”的一个插件，它不怎么跳出来刷存在感，但是你不装它，那些莫名其妙的代码规范错误啊、小坑啊，迟早会出事。

这个插件就是阿里的 Alibaba Java Coding Guidelines，我当时装它纯属是看它名字响，结果一用——卧槽，像是突然有个老程序员坐你旁边了，什么命名规范、类结构、甚至 if 语句多写了个空格，它都能“叨叨”你。

安装也简单，IDEA 插件市场搜 Alibaba Java Coding Guidelines，点安装，重启IDE就行了。

最有意思的是它的那个“问题等级”分类，分啥呢？分成 Code Style、Code Problem、Best Practices 三种。前两个你一看就懂，最后一个其实是劝你别作死，比如你 new 一个线程但忘了关闭，或者 try-catch 没处理异常。这些你可能一开始觉得啰嗦，但真遇到线上的锅，就会想给它磕头。

我记得有次我写了段循环的逻辑忘加 break，它直接标红提示我“switch case 中可能存在 fall-through”，点一下自动修复就加了 break，舒服得很。

代码强迫症的福音：CheckStyle

然后就是 CheckStyle，这个我得提醒一下，不是所有人都爱它，尤其是那种“我代码我做主”的同学。但我们团队用了以后，代码合并冲突少了不少，因为风格都统一了，变量起名、注释规范、缩进位置，都得过它这一关。

CheckStyle 的强项在于可配置，你可以写一套 XML 规则，也可以直接套用阿里的规范，然后就会在保存代码时自动触发检查，红一片给你看。

但更妙的是它跟上面那个阿里插件居然能协同工作——有的规则两个插件都会报，但 CheckStyle 更严。比如变量名要求是驼峰，阿里插件提醒你说“建议这么写”，CheckStyle就直接红色报错，不让你提交。

代码安全的“防火墙”：PMD

说到安全这块，我得提一下 PMD，不装的时候我真没意识到写个 getter/setter 还能踩安全雷。

它主要是扫那种“容易埋雷”的写法，比如：

if (a = b) { // 明显写错了，应该是 ==

}

它能一眼识破你是不是不小心把赋值写成判断了，还会提示你“这段代码从未使用”，或者“这个 catch 块是空的”。

PMD 的安装跟前两个一样，IDEA 插件中心直接装。用起来稍微重了一点，每次分析会卡个一两秒，但放心，能给你省下线上一堆重启。

FindBugs 已死，SpotBugs当立

以前写 Java 的老哥们可能都用过 FindBugs，但是它好几年没更新了，现在都转用 SpotBugs。你别看名字像“山寨版”，其实它是 FindBugs 的官方继任者。

这个插件的重点就是找“那些你写了但从没跑到”的代码，或者“这个对象可能是 null，你还非要调方法”。比如我之前在一个工具类里写了个 public static 方法，没注意 return 了个可能为 null 的字段，SpotBugs 一跑，立马提示 “Possible null dereference”。

而且它还能跟 PMD 搭着用，一个偏语法逻辑，一个偏运行安全，两个轮着报错，Bug 真的少了一半不止。

SonarLint：代码质量的“指挥官”

最后这个 SonarLint，我是一开始不太感冒，因为听起来就像个企业大哥用的玩意。但后来看我们组的小李用它配合 SonarQube，每次提交代码都能看到详细的质量评分，代码异味（code smell）提示也很精准，才发现这个东西是真能“管住你手”的。

尤其是它 2025 年开始支持一些新规则，比如你用 Java 21 写 stream 操作，SonarLint 会根据官方 best practice 直接建议你替换成更高效的写法，比如：

list.stream().filter(Objects::nonNull).count();

它会提示你 .filter(Objects::nonNull) 可以提取为通用方法，提升代码复用性。关键是它是边写边分析，没等你 run，就已经告诉你“不建议这么写”。

如果你有搭 SonarQube 服务，那 SonarLint 会自动连接平台上那套质量规则，确保你的代码不光能跑，还得优雅地跑。

联合作战：打造 Bug 防御体系

我后来做了个实验，在新项目里一口气装了上面这五个插件，然后把代码提交前强制走一遍检查流程。

结果呢？以前我们提测会遇到那种“为啥又漏了个 null 判断”“为啥又 catch 了啥也没处理”，现在基本没了，甚至有几次 QA 跟我们说：“你们这版本代码好像干净得有点不真实。”

我组的小吴说了一句特别在理——“这些插件就像代码审查机器人，你写代码的时候，它就已经在给你做 code review 了。”

你说这些插件能不能完全杜绝 Bug？肯定不能。但就像车里加个行车记录仪，你开车可能还是会撞，但撞了起码知道为啥撞、怎么撞的。

现在我几乎已经离不开这几个插件了，尤其是那种刚进组的新人，我会第一时间发他们个配置清单，就像打游戏前先装好外挂，不然真的追不上。

行了，我这边还有代码要改。对了，如果你们谁最近在招实习生，记得提醒他们别在代码里写“System.out.println”，这些插件一上来就给你爆出来……

-END-

原谅来源：https://mp.weixin.qq.com/s/IyVOmqnBJjQpchos7tTrEA?click_id=31