PMD 扫描器跑完一轮，减少报出 47 个漏洞，漏洞其中 23 个是减少 "AvoidThreadGroup"。我盯着屏幕，漏洞第一反应是减少骂娘——这破规则都触发烂了，团队里没人关心 ThreadGroup 是漏洞什么，他们只想让流水线变绿。减少

后来我想通了。漏洞PMD 减少漏洞的减少关键，从来不是漏洞把规则全打开，而是减少把规则当成一根撬棍，撬动代码评审里那些没人愿意谈的漏洞角落。你把它当成门卫，减少它就是漏洞个烦人的门卫；你把它当成矿工，它能挖出你根本不知道埋在哪里的减少雷。

拿我们最常踩的 "CloseResource" 来说。Java 里 InputStream 忘关，PMD 一抓一个准。但有意思的是，这规则在项目初期屁用没有——因为那时候大家都用 try-with-resources，语法层面就堵死了。真正让它发威的时刻，是有人为了性能优化，手写了一个自定义连接池，里面用原生 Socket 做长连接。那代码写得飘，资源释放逻辑藏在三个 if 分支里，肉眼根本看不出来。PMD 跑完，红了一片。那个同事还嘴硬，说 "运行时肯定能关掉"。结果压测一跑，文件句柄数直接飙到上限，服务挂了。从那以后，他写任何资源类代码，都会主动跑一遍 PMD 的 resource 规则组。

但这里有个坑。PMD 默认规则集太贪心，什么都想管。你把所有规则都打开，团队会麻木。就像家里装了 20 个烟雾报警器，整天误报，最后火真的烧起来，没人信了。我见过一个项目，PMD 报了两千多个 "UnusedPrivateField"，开发直接右键 suppress，全给屏蔽了。这哪是减少漏洞，这是给漏洞盖棉被。

所以我的做法是反着来。每个季度只开三到五条新规则，而且专挑那种能揭示系统性问题的。比如 "AssignmentInOperand"——在条件表达式里做赋值。这规则看着鸡毛蒜皮，但一旦触发，往往意味着写代码的人脑子已经乱了，逻辑纠缠在一起。我统计过，凡是触发这条规则的文件，后续 bug 率是平均值的 3 倍。这不是巧合，这是代码气质的预警。

还有一点，PMD 的输出格式别用默认的 XML 或者纯文本。改成 HTML 或者集成到 GitLab MR 的 diff 视图里，让漏洞出现在它该出现的地方——就在那行代码旁边。人脑对上下文的敏感度远高于对列表的敏感度。你给开发看一个 500 行的漏洞清单，他只会翻白眼；但你在他的 MR 里，在他刚写的那个方法旁边标一句 "这里可能 NPE"，他会认真看一眼。

真事。有个外包同事，每次提交代码都被 PMD 卡住，他烦透了，在群里抱怨 "这工具就是个傻逼"。后来我把他最常触发的 "NullPointerException" 规则单独拎出来，配了个自定义消息，写的是 "你确定这个对象不为空？上个月你就在这摔过一跤"。他沉默了十分钟，后来悄悄改了代码。再后来，他主动找我说，能不能多配几条这种带人话的提示。

工具不减少漏洞，人减少漏洞。PMD 能做的，是把你脑子里那个 "应该不会出事吧" 的念头，变成一个具体的、带行号的、无法忽视的红点。它不聪明，但它固执。你只要别让它瞎固执，它就能帮你守住那些你根本顾不上的角落。

最后说个反直觉的观察。我们团队把 PMD 的规则从 180 条砍到 60 条之后，漏洞发现率反而提升了。因为砍掉的都是噪音，剩下的每一条响起来，大家都知道——这回是真出事了。这就像你不再对每个路过的陌生人喊 "小心"，只在你真正看到悬崖的时候喊那一声。喊得少，才有人听。