先说个我自己的情况前几年在团队里负责一个跨平台的 C 服务端模块代码量不算夸张两三个仓库加一起大概 30 万行但因为是老项目迭代过来的历史包袱很重很多指针释放、资源管理的逻辑散落得到处都是。每次发布前最害怕的不是需求改不完而是那种“本地跑得好好的一上线就崩”的偶发问题——不崩溃则已一崩溃就是段错误、内存泄漏、未定义行为。靠人眼 review 抓这种问题效率太低而且 review 本身就是最贵的环节两个人盯着屏幕半小时往往只揪出几个风格问题真正的深水区一点没碰到。后来我把 CodeChecker 这套静态检查工具引入到了日常开发流程里效果非常直接上线前能够提前发现一批真实的资源泄漏和空指针解引用问题很多以前要等到崩溃日志出来才排查的毛病在提交阶段就被拦住了。这篇文章就把我从零开始用 CodeChecker 的过程、踩过的坑、以及怎么把它接进团队流程里的经验完整写出来适合正在做 C/C 开发、有代码质量诉求但还没认真选型过静态检查工具的人参考。1. CodeChecker 到底解决什么问题1.1 静态检查、静态分析这些概念到底指什么静态检查Static Check这个词听起来有点学术其实说白了就是“不运行代码直接读代码找毛病”。动态测试比如单测、集成测试是你把程序跑起来喂进去数据观察行为而静态检查是在编译之前或编译期间通过语法树、控制流图、符号执行这些手段去推导代码里可能存在的缺陷路径。两者的关系不是替代是互补——动态测试能看到“跑出来的结果对不对”静态检查能看到“哪些路径根本不该走走了就会炸”。在 C/C 这个领域里静态分析工具大致分成两类。一类是 Cppcheck、Clang-Tidy 这种偏向“规则检查 模式匹配”的工具它们能抓变量未初始化、资源未释放、循环边界写错这类常见问题速度快误报率相对可控。另一类是 Clang Static Analyzer 这种真正做符号执行Symbolic Execution的深度分析器它会维护一组抽象状态沿着函数的每条路径模拟执行遇到malloc就跟踪指针状态遇到if分支就探索两个方向然后判断哪些路径会导致空指针解引用、内存泄漏、使用已释放内存等问题。这种分析比单纯匹配代码模式要聪明得多但开销也大对编译信息的要求更高。CodeChecker 的定位就是把这套东西整合在一起的“一站式静态检查工具”。它由 Ericsson 开源底层基于 LLVM/Clang核心引擎是 Clang Static Analyzer 和 Clang-Tidy但 CodeChecker 本身并不是一个全新的分析器它更像一个完整的分析平台负责调用编译器、管理编译数据库、收集分析结果、去重、存储到数据库、通过 Web 界面展示还支持增量分析和报告对比。换句话说Clang Static Analyzer 是那个真正干活的“分析引擎”而 CodeChecker 是做工程化落地的“外壳和平台”。没有这个外壳你用 Clang Static Analyzer 的方式是命令行直接敲clang --analyze一次只能处理一个文件结果散落在一堆.plist文件里看结果要靠人工翻文件有了 CodeChecker结果被结构化存储有 Web UI有趋势图有 diff 模式才真正具备大规模落地的可能。1.2 主流方案横向对比Cppcheck、Clang-Tidy、CodeChecker 怎么选很多朋友在选择静态检查工具时会在 Cppcheck、Clang-Tidy、CodeChecker 这三者之间犹豫。我的建议是不要把它们当成不同选项而是理解成不同层级的工具它们解决的问题不一样。Cppcheck 的优点是轻量、部署快、不依赖编译环境它靠自己的内置解析器对源码做语法层面的分析即使没有完整的编译命令也能跑。缺点是它对模板、宏展开和跨编译单元的分析能力非常有限复杂项目的误报率明显偏高。它适合作为“随手蹭一眼”的检查工具独立跑一遍看看有没有一眼能看出的低级问题。Clang-Tidy 是 LLVM 官方提供的 lint 工具由 Clang 前端驱动所以它是真正理解代码语义的能识别宏展开后的真实代码能感知模板实例化还能做很多现代 C 风格检查比如modernize-*系列规则。但 Clang-Tidy 本质上定位在“风格 局部正确性”层面它对跨函数的路径敏感分析能力不强不会模拟执行也不会跟踪一个指针从malloc到free的完整生命周期。CodeChecker 则站在更上层它把 Clang-Tidy 和 Clang Static Analyzer 都纳入自己的检查器集合里也就是说你可以在同一个平台里同时跑“规则检查”和“深度路径分析”。再加上它还支持结果去重、历史差分、Web 浏览、基线对比这些工程化能力所以如果你要的是“团队级、项目级、可长期积累的静态分析系统”CodeChecker 是三者里唯一能把整个流程闭环的。1.3 CodeChecker 的核心优势到底在哪绕开官方文档那些功能列表我根据自己的实际体验总结 CodeChecker 最值钱的三个核心优势。第一个是结果可持久化和历史可追溯。你用 Cppcheck 跑完一轮输出一个报告文件过两个星期再跑你很难快速说出“这轮比上轮新发现了哪些问题”因为两个报告之间没有建立关联。CodeChecker 会把每一次分析结果存储为一条 Run 记录数据库会记录每个 Bug 的指纹它根据代码位置、检查器名称、缺陷路径生成唯一标识你可以随时挑选两个 Run 做对比看到“新增、已修复、未解决”三类问题的统计这其实就是代码质量提升的进度条。第二个是增量分析和 Diff 模式。大型项目全量分析一次可能需要几十分钟甚至更久不可能每次代码提交都全量跑。CodeChecker 支持增量模式它会基于 Git/SVN 变更信息只重新分析发生变更的文件以及受影响的编译单元然后把新结果与上一次的结果合并这样一轮增量分析通常只需要几分钟。实际开发中我一般是提交代码前只分析改动文件每个迭代结束前再全量跑一次成本和效率非常平衡。第三个是部署形态更贴近真实 CI/CD 环境。它的 Web 服务器模式支持 SQLite、PostgreSQL、MySQL 多种后端可以部署在服务器上供多人访问命令行客户端也支持cmd diff等操作可以很方便地集成进 GitLab CI、Jenkins 这类流水线里。不是所有静态检查工具都愿意做这一层工程化投入但这恰恰是团队落地时最关键的需求。2. 环境准备与安装踩坑2.1 依赖说明与版本选择CodeChecker 本身是 Python JavaScript 的混合项目分析能力来自 Clang 的各个可执行文件。安装它之前你需要确认三个前提系统能运行 Python 3建议 3.6新版基本要求 3.8、有 Node.js 运行时用于 Web 界面组件、有 Clang/LLVM 相关工具链至少需要clang、clang-tidy、clang-tidy-diff等这些是执行实际检查的引擎。注意系统的默认 gcc 是 GNU 编译器跟 LLVM 是两个体系静态分析阶段 CodeChecker 最终会调用 clang 系的二进制所以如果你服务器上只有 gcc分析是跑不起来的。版本选择上我个人的建议是优先用 LLVM 官方源的 Clang版本尽量和 CodeChecker 兼容。比如你用的是较新的 Ubuntu直接apt install codechecker安装的版本可能偏旧而 CodeChecker 的更新迭代又不慢所以我更推荐从源码安装最新版而不是贪图 apt 的省事。这里有个经常踩的坑系统里如果存在多个版本的 clangCodeChecker 可能默认找到的是旧版本导致部分检查器不可用。解决办法是显式指定编译器路径比如export CC/usr/bin/clang-14、export CXX/usr/bin/clang-14或者使用CodeChecker analyze --jobs 4 --cppcheck这类参数时明确指定可执行文件位置。2.2 三种安装方式的选择逻辑安装 CodeChecker 主要有三条路系统包管理器、Docker 容器、源码编译。我建议按场景来选。如果只是本地想快速体验一下系统包管理器最方便。Ubuntu 或 Debian 系可以执行sudo apt install codecheckermacOS 用户可以用 Homebrewbrew install codechecker安装完确认一下版本号CodeChecker --version不过这种方式装的 CodeChecker 一般版本比较保守而且不一定包含最新的检查器集所以如果你要分析的项目用到了较新的 C 标准或者想体验最新规则还是推荐源码安装。源码安装的步骤也比较清晰# 拉取仓库 git clone https://github.com/Ericsson/codechecker.git --depth 1 cd codechecker # 创建虚拟环境强烈建议 python3 -m venv venv source venv/bin/activate # 安装 Python 依赖 pip install --upgrade pip pip install -r requirements.txt # 编译并安装 make package上面的make package会生成一个build/CodeChecker目录把发布版打包进去。之后你把build/CodeChecker/bin加进PATH或者在系统 PATH 里做软链就可以全局使用了。注意源码安装之前请确保 Node.js 已安装否则 Web UI 部分无法构建完整。如果是要部署到 CI 环境或服务器上我更推荐用官方 Docker 镜像。Docker 方式最大的好处是免去所有环境依赖的麻烦便于保持 CI 环境的一致性只需要注意把分析结果目录和数据库目录用 volume 挂出来避免容器重建后数据丢失。2.3 安装后的环境验证装完之后我习惯用一小段代码先验证整个链路是否正常。新建一个test.c#include stdlib.h void leak(int cond) { char *p malloc(1024); if (cond) { return; // 这里 return 时没有释放 p构成内存泄漏 } free(p); }然后生成它的编译数据库并运行分析如果这一步能正常报出Memory leak说明 CodeChecker 的调用链是通的。具体命令用法我在下一节完整展开。顺带提一个隐藏的排错点如果你在分析时遇到Failed to run: /usr/bin/clang-tidy这类报错大概率是没装 clang-tidy或者装了但不在 PATH 里。Debian/Ubuntu 下可执行sudo apt install clang-tidy然后重新尝试。还有如果系统里存在多个 clang 版本建议检查一下/usr/bin/clang实际指向的是哪个版本必要时用 update-alternatives 切换这能避免很多“为什么有些检查器莫名失效”的怪问题。3. 使用 CodeChecker 跑通第一次分析3.1 第一步生成编译数据库CodeChecker 分析 C/C 代码时需要知道每个源文件是用什么命令编译的包括头文件路径、宏定义、编译选项等。这些信息被集中放在一个叫compile_commands.json的文件里也就是编译数据库Compilation Database。没有这个文件Clang 就不知道-I指向哪、某个宏是否定义过分析结果会变得一团糟而且大量误报。生成编译数据库的常见方式有三种。方式一使用 CodeChecker log。这是 CodeChecker 内置的构建日志捕获工具用法是CodeChecker log --build make -j4 --output compile_commands.json原理是让构建过程的所有编译命令经过 CodeChecker 的包装器从而被记录到输出文件中。如果你用的是 CMake 生成的 Makefile也可以直接用make作为构建命令。方式二利用 CMake 的导出能力。如果你的项目已经用 CMake 构建那最简单的是在 CMake 配置时加一个开关cmake -DCMAKE_EXPORT_COMPILE_COMMANDSON ..构建后CMake 会在 build 目录下自动生成compile_commands.json。这个方法不需要任何额外工具最干净。方式三使用 Bear。这是 Linux 下另一个工具用法是bear -- make -j4它也能拦截编译命令生成编译数据库。但既然 CodeChecker 已经内置了 log 功能一般情况下不需要额外引入 Bear。提示生成compile_commands.json之后可以先打开文件简单确认一下内容。如果里面每个编译条目都带command、directory、file三个字段说明生成成功。如果文件内容是空的八成是构建命令没有走编译器包装器比如你自己写的 shell 脚本直接调用了 gcc而不是调用了 make/cc 命令需要调整构建方式。3.2 第二步使用 analyze 执行静态分析有了compile_commands.json就可以正式执行分析CodeChecker analyze compile_commands.json --output ./reports --clean上面命令的含义是读取编译数据库调用 Clang Static Analyzer 和 Clang-Tidy将所有分析结果输出到./reports目录。--clean表示每次分析前清空旧的输出目录避免上次残留结果影响判断。这里我多说几个常用的进阶参数。控制并发分析的有--jobs N默认是 CPU 核心数。如果你的机器内存不太够建议调小一点因为 Clang Static Analyzer 的内存占用比较高并发太高容易 OOM。控制检查器开合的是-eenable和-ddisable参数。比如我只想开 Clang-Tidy 的bugprone-*规则可以这样CodeChecker analyze compile_commands.json -o ./reports \ -e bugprone-* \ -d clang-diagnostic-*在默认情况下CodeChecker 启用的是官方认为“安全”的检查器集合不一定能覆盖项目需要的所有规则。建议先用CodeChecker checkers --list看看当前环境到底支持哪些检查器再按需启停。注意CodeChecker checkers --list需要联网吗不需要它只是列出本地安装的分析器能力。如果想开启全部检查器可以使用--enable-all。但是我不推荐一上来就--enable-all因为大量规则会带来巨量报告其中不少是噪音反而让你忽略真正重要的问题。我常用的套路是先只开alpha相关的核心安全检查器比如空指针、内存泄漏、死代码等工具跑顺了之后再逐步扩大规则集。还有一个非常实用的参数是--file可以只分析某个指定文件例如CodeChecker analyze compile_commands.json -o ./reports --file src/core/network.cpp这在本地开发、只想扫描自己改动过的文件时非常方便能省大量时间。3.3 第三步结果呈现与 Web 可视化分析结果生成后你可以先直接看纯文本CodeChecker parse ./reports这个命令会把./reports里的报告目录遍历一遍以控制台输出的方式展示每个 Bug 的文件、行号、检查器名称、严重级别和简要描述。如果你只是想快速扫一眼结果这个命令就够了。但 CodeChecker 最体现价值的是 Web 可视化。整体流程是先启动服务端再把分析结果“存”进去。第一步启动服务器CodeChecker server --host localhost --port 8001 --workspace ./ws--workspace是数据存储目录如果你希望在多人环境中共享分析数据可以通过配置使用 PostgreSQL 等数据库作为后端但本地体验 SQLite 即可。第二步把本轮分析结果存为一条 Run 记录CodeChecker store ./reports --url http://localhost:8001 --name myproject --tag v1.0这一步将./reports目录下的报告导入到 CodeChecker 服务器中存储为名为myproject、标签为v1.0的分析记录。成功后打开浏览器访问http://localhost:8001就能看到 Web 界面。Web UI 里你可以在项目列表点击myproject进入详情浏览器会展示每一个缺陷的摘要列表点击任意一条记录能看到完整的源代码上下文、Bug 路径、控制流图等。刚开始用 Web UI 可能会觉得信息量很大我建议关注三个核心字段Severity严重级别、Checker name检查器名和Path代码位置。先把Critical和High级别的问题消化完再去处理Medium和Low。现实情况里很多团队只处理前两级效果就很可观了。3.4 增量分析和 diff 模式的威力全量分析适合在版本发布前做但日常开发中我们更需要一种“只报告我这次改动引入的问题”的机制。CodeChecker 的增量分析才是它真正拉开差距的地方。最简单的增量分析场景是你已经有了上一轮的存储记录称为 baseline这一轮改动之后重新分析然后用差分查看新增问题。具体操作是# 1. 重新跑分析只分析变更文件可通过 --file 指定 CodeChecker analyze compile_commands.json -o ./reports_new --file src/core/network.cpp # 2. 解析结果并查看新增问题 CodeChecker parse ./reports_new # 3. 把新结果存进去 CodeChecker store ./reports_new --url http://localhost:8001 --name myproject --tag v2.0 # 4. 在 Web UI 中选择两个 Run 进行 diff或者用命令行对比 CodeChecker cmd diff -b myproject:v1.0 -n myproject:v2.0 --url http://localhost:8001--tag参数非常关键它是 Run 记录的标签有了它你才能精确找到“上次跑的那一条记录”做对比。Diff 结果的三种分类新增问题、已解决问题、未解决问题。我在实际开发中会把“新增问题数必须为 0”作为合并请求的硬性门槛。这个门槛看似严格其实落地并不难因为增量分析只关心你改动引入的新缺陷不会把历史债务一起算在你头上。还有一个小技巧CodeChecker 支持在 diff 时过滤到特定文件这样在代码评审时能快速看到“这个 MR 到底引入了什么潜在风险”评审效率提升不是一点半点。4. 实战配置、流程与常见问题4.1 如何配置检查器检查器的配置是 CodeChecker 使用中最需要花心思的地方。默认配置覆盖面不够广但--enable-all又太激进所以一定要结合项目的语言版本、业务场景来定制。我的做法是先跑一次CodeChecker checkers --list这个列表通常非常长可以从里面挑出几组适合自己项目的规则。对于一般的业务代码至少应该保留这些类别记忆体/资源管理相关alpha.unix.MallocWithDelete、cplusplus.NewDeleteLeaks、unix.Malloc等负责发现内存泄漏、重复释放、分配释放函数不匹配。空指针相关core.NullDereference、core.CallAndMessage等对空指针解引用非常敏感。逻辑性错误core.DivideZero、deadcode.DeadStores等能发现除零、无效赋值等明显逻辑错误。Clang-Tidy 的 bugprone 系列bugprone-*涵盖了很多常见 C 编码陷阱。实操命令示例CodeChecker analyze compile_commands.json -o ./reports \ -e core.NullDereference \ -e core.DivideZero \ -e cplusplus.NewDeleteLeaks \ -e unix.Malloc \ -e deadcode.DeadStores \ -d llvm* \ -d google*-d llvm*表示屏蔽 LLVM 本身的一系列风格检查器因为很多并不适合业务团队干扰太大。这里有一点需要注意CodeChecker 的检查器名称支持通配符所以可以写成-e bugprone-*这种形式但通配符的匹配规则在你本地环境的版本上略有差异建议小范围试用确认无误后再全量启用。除了命令行参数还可以把规则写进配置文件。创建一个checker_config.json{ checkers: [ core.NullDereference, core.DivideZero, cplusplus.NewDeleteLeaks, unix.Malloc, deadcode.DeadStores ] }然后加载CodeChecker analyze compile_commands.json -o ./reports --checker-config checker_config.json这种方式的好处是配置文件可以入库版本管理团队评审检查器变更时也容易追踪。我见过不少团队在“怎么敲命令”上反复传授却没人把规则集沉淀成配置文件这是非常可惜的。4.2 误报的处理与抑制机制静态分析工具的误报False Positive永远是一个绕不开的话题。Clang Static Analyzer 在路径搜索中会探索很多理论上可能但实际到不了的路径所以误报不可能完全消除。关键是建立一套高效的“误报处置机制”而不是单纯抱怨误报多。首先是代码内抑制。CodeChecker 支持在代码里通过注释来抑制指定检查器的告警void foo(int *p) { if (!p) { return; } // codechecker_suppress [core.NullDereference] 经过上层校验这里不可能为空 int x *p; }上面注释格式中的codechecker_suppress是 CodeChecker 的专有抑制标记后面紧跟需要抑制的检查器名然后再写一行说明。注意抑制声明要放在告警行之前才好让解析器匹配到。其次是全局抑制列表。如果某些第三方代码经常误报不建议在代码里加抑制因为要改动第三方源码更好的做法是在分析时用--suppress参数指定一个全局抑制文件CodeChecker analyze compile_commands.json -o ./reports --suppress suppress.txtsuppress.txt中的每一行可以写成如下格式core.NullDereference: third_party/*这样指定检查器在指定目录下的告警全部被抑制。还有一种办法是配置 skip 列表直接把某些文件或路径排除出分析范围CodeChecker analyze compile_commands.json -o ./reports --skip skip.txtskip.txt支持 include/exclude 两种模式例如-*/build/* -*/third_party/* -*/tests/*第三方的代码一般不太需要做静态分析排除掉可以显著节省分析时间。在机制上我强烈建议团队对“误报”打标签而不是直接删除报告。CodeChecker 支持在 Web UI 上对报告进行评论、状态管理等操作你可以把确认为忽略的报告标记为false positive并在评论中写明理由。这一点能帮助团队积累“哪些检查器在该项目里值得信任”的经验时间长了误报容忍度会越来越精准。4.3 常见问题速查表我从实际使用里挑出了几个出现频率很高的问题整理成一张速查表。问题现象|可能原因|解决办法compile_commands.json生成失败或内容为空 | 构建命令未经过编译器包装器或 Bear/CodeChecker log 权限不足 | 改用 CMake 的CMAKE_EXPORT_COMPILE_COMMANDS或检查构建命令是否需要sudo分析时提示clang: error: unknown argument| 编译命令里混入了 GCC 专属参数比如-m32、-fno-omit-frame-pointer的某些平台选项| 在 analyze 时加上--ignore参数忽略特定编译标志或调整编译数据库将这些参数过滤掉 内存占用过高导致分析进程被杀 | Clang Static Analyzer 并发数过高 | 调低--jobs同时检查是否有不必要的编译单元被全量纳入用--file缩小范围 Web UI 访问不了 | 服务器接收端口未开放或监听地址错误 | 确认CodeChecker server --host 0.0.0.0 --port 8001的监听地址并确保防火墙放行 某一类检查器报告 0 条但代码里明显有相关问题 | 系统缺少对应的 clang-tidy 插件或该检查器未启用 |CodeChecker checkers --list查看是否支持该检查器再用-e显式启用 代码中加了codechecker_suppress注释但抑制无效 | 注释格式或位置不对 | 确认注释应放在告警行的上一行或同一行且codechecker_suppress后面必须跟检查器名其中第一个坑是最常见的。很多人在用CodeChecker log生成编译数据库时项目本身用的是自定义构建脚本脚本内部直接调用/usr/bin/gcc或者通过cc1这类底层程序CodeChecker log 包装不到最后得到空文件或残缺文件。遇到这种情况最稳妥的方案还是回到 CMake 或 Make 的构建栈上来。还有一点想提醒CodeChecker analyze 分析时如果编译单元里包含了系统头文件路径而系统头文件路径又引用了 Clang 环境不存在的头文件可能会爆大量fatal error: stdio.h file not found这样的错误。这通常是因为 clang 找不到系统头文件路径需要给 analyze 传--extra-arg或者--extra-arg-before参数补充-isystem路径CodeChecker analyze compile_commands.json -o ./reports \ --extra-arg -isystem /usr/include/x86_64-linux-gnu如果项目里用了第三方库记得也要把第三方库的 include 路径加进去。这一步做好了分析时的“假阳性文件缺失错误”会大幅减少。4.4 个人心得在团队落地时的一些建议工具本身不难难的是让团队真正接受并坚持使用。我在落地 CodeChecker 的过程中总结了几个比较关键的实操建议。第一个建议是先跑出几轮基线再强调“零新增”。不要工具一引入就立刻把“历史问题清零”当作目标一个老项目往往有成千上万条历史告警硬要清零会让团队产生极强的挫败感。我推荐的做法是先全量跑一遍把结果存成 baseline然后跟团队约定——新提交的代码不允许产生新的 Critical/High 问题。这样一来历史问题慢慢消化新增问题立即拦截团队不会觉得“一上来就背了几千个 bug 的锅”。第二个建议是把 CodeChecker 的 diff 结果接进评审流程。在代码合并请求的描述里贴出本次改动的告警变化统计包括新增、修复、未解决数量这样评审人不用自己重新跑分析也能快速判断改动是否有质量问题。我个人在 MR 模板里就固定加了“Static Analysis Result”一栏让开发者在提交时附上CodeChecker cmd diff的输出摘要这个习惯一旦养成整个团队的代码质量水位会明显上升。第三个建议是定期校准规则集。静态分析工具不是一次配完就永远不变的。随着项目特性变化、依赖库更新旧规则可能不再重要新规则可能更契合项目的痛点。我通常每季度做一次规则集 review结合上个季度的数据哪类问题最多、哪类误报率最高调整下一次的检查器配置。这种“用数据反哺配置”的节奏比拍脑袋开关检查器有效得多。第四个建议是要重视分析环境的稳定性。静态分析工具对编译器版本、头文件路径极其敏感如果每次分析的环境不一样历史结果对比就没有意义。所以当 CodeChecker 进入持续集成流程之后建议把分析过程和编译过程放在同一个环境里最好用固定版本的 Docker 镜像避免因为环境不一致导致同一段代码不同的分析结果。一些最后的经验CodeChecker 这类的静态检查工具说到底只是一个“放大镜”它能放大你在代码里埋下的雷但不能替你拆雷。在实际使用中我最深刻的体会是工具的价值不在于一次性扫出多少历史问题而在于能不能形成一个持续反馈的闭环——提交代码时发现问题修复后看到问题消失下一个迭代里新问题又被拦截。这个闭环一旦转起来代码质量就会像滚雪球一样越滚越好。如果你正准备给自己的项目引入静态检查我建议不要急着上很多高级特性先从一个目录、几个严重级别入手跑通“编译数据库生成 → analyze → store → Web 查看 → diff 对比”这个完整流程再逐步铺开。我自己最开始也只是让 CodeChecker 每周在测试分支上全量跑一次大概跑了两个月之后才把增量分析正式接进了 MR 流程。现在看来这个循序渐进的方式让整个团队接受度很高几乎没有遇到“工具太复杂导致没人用”的问题。最后分享一个小技巧做静态分析的时候不一定非要等 CI 跑完才看结果。如果你在一个比较大的项目上开发完全可以在提交之前先用CodeChecker analyze --file 你改的文件快速扫一遍确认没有新增问题再提交。这一下虽然只花几十秒但能给你省下提交之后一轮轮 review 和 CI 的时间。这个习惯我一直保留到现在也是我给所有刚接触 CodeChecker 的同事的第一条建议。