用 CodeArts Check 把好代码关在合入前：质量门禁实战

"本地能跑，提交就完事"是不少开发团队的真实情况。可等代码合进去、线上出问题，回头查才发现是空指针、资源没关、命名一团糟。CodeArts Check 做的就是在这之前拦一道：代码还没合入主干，先自动扫一遍，发现问题直接卡住，不让带病代码进仓库。这篇文章聊聊它到底能查什么、怎么接进流水线，以及实际用起来的一些体会。

一、代码检查解决的是什么问题

人工 code review 很贵，也看不全。语法规范、潜在空指针、SQL 注入风险、圈复杂度过高这类问题，靠人眼扫既慢又容易漏。静态代码检查（SAST）能在不运行程序的情况下，对源码做规则匹配和语义分析，把这些隐患提前暴露出来。

二、CodeArts Check 的基本工作模型

它的核心是一个"检查任务"绑定一个代码仓库（CodeArts Repo 或其他 Git 仓），配一套规则集，然后触发扫描。扫描结果按严重级别（致命/严重/一般/提示）归类，给出文件、行号、规则说明和修改建议。

不同语言的规则侧重点不同：

• Java：空指针解引用、资源未关闭、equals 比较顺序、魔法值。
• Python：未使用导入、变量遮蔽、危险的 eval、异常处理过宽。
• C/C++：数组越界、内存泄漏、悬空指针、未初始化变量。
• JavaScript/Go：未声明变量、隐式类型转换、错误吞掉。

规则集可以按语言选，团队也能基于内置集做裁剪，关掉不适合自己项目的规则，避免噪声太多把人搞烦。

三、把检查接进流水线

单独跑检查容易忘，正经做法是挂到流水线（CodeArts Pipeline）里，作为合入门禁：

1. 在 CodeArts Check 创建检查任务，关联仓库和分支；
2. 在流水线里加"代码检查"阶段，配置阈值（比如致命+严重问题数 > 0 就失败）；
3. 开发者提 MR 触发流水线，检查不过就阻止合入；
4. 扫描报告里点开问题，按建议改完再重新跑。

这样"合入"和"质量达标"被绑死，比靠自觉靠谱得多。一个典型的流水线阶段顺序是：代码拉取 → 代码检查 → 编译构建 → 单元测试 → 部署。代码检查尽量前置，越早发现问题修复成本越低。

四、一个"改前改后"的真实情况

检查曾报过一个"资源未关闭"问题，原代码是这样：

public String read() throws IOException {
    FileInputStream in = new FileInputStream("a.txt");
    return new String(in.readAllBytes()); // in 没关，异常时泄漏
}

报告里给了建议，改成 try-with-resources 后通过：

public String read() throws IOException {
    try (FileInputStream in = new FileInputStream("a.txt")) {
        return new String(in.readAllBytes());
    } // 自动关闭，无论是否异常
}

这种问题肉眼在 review 时很容易滑过去，工具一秒就揪出来了。

五、一条可落地的推行路线

• 先开默认规则集跑一轮：别一上来就定制，用内置集扫一遍看存量问题有多少。
• 分级处理存量：致命/严重优先修，提示级的可先忽略，否则历史欠账会把新人劝退。
• 门禁只卡新增：把规则设成"仅检查本次变更的代码"，让存量问题慢慢还，而不是一次性压垮团队。
• 定期收紧：等团队适应了，再把门禁阈值调到更严。

六、经验小结

第一，规则不是越多越好。我们一开始全开，每天几十条提示级告警，没人看，反而把真正严重的问题淹没了。后来按项目关掉噪声规则，告警量降下来，大家才真正点进去看。

第二，门禁阈值要循序渐进。直接"零容忍"会让所有 MR 都红，开发会想办法绕过。先允许存量，卡住新增，团队接受度高很多。

第三，检查报告的"修改建议"很实用，很多规则直接给了改法，新人照着改还能学规范。

第四，误报难免。个别规则在特殊写法下会误报，CodeArts Check 支持对具体文件或规则做忽略配置，但该忽略要有据可依，别一刀切关掉整条规则。

总结

CodeArts Check 的价值是把代码质量从"靠人自觉"变成"靠门禁卡住"。关键不在于工具多强，而在于怎么用：先跑默认集看存量、分级处理、门禁只卡新增、再逐步收紧。把它挂进流水线，让每次合入都过一遍，长期看能省下不少线上救火的功夫，也让团队的代码风格自然地统一起来。