静态分析沿控制流和数据流查找空指针、越界、未初始化值、资源泄漏与可疑并发，不需要执行目标程序，适合难以完整测试的固件。它不会证明程序“没有 bug”，但能在代码进入板子前持续发现一批人眼容易漏掉的路径。

生成 compile_commands.json→运行编译器告警与分析器→按严重度归类→修复或记录理由→CI 阻止新增缺陷
检查图编译器、分析器和人工审查各自覆盖不同类型的问题。
编译告警最快发现类型、格式、未使用和明显控制流问题。编译数据库让工具看到真实 include、宏和目标架构参数。数据流分析追踪空指针、未初始化值、资源和边界跨函数传播。规则集MISRA 等规则需要结合项目风险和例外处理，不应盲目全开。基线先记录遗留告警，防止新改动继续扩大问题规模。复核理由误报、偏离规则和无法修复项都要留下可审计说明。

让工具分析真实构建，而不是猜测源码

compile_commands.json 或等价构建信息会告诉分析器使用哪个编译器、头文件、宏、语言标准和目标架构。没有这些信息，工具可能在错误的条件编译分支里分析，结果要么噪声极多，要么漏掉目标板专用代码。交叉编译项目尤其需要把 sysroot 和编译参数传完整。

规则要逐步收紧，CI 要阻止倒退

先把高置信度缺陷和编译器告警清掉，再按模块启用更严格的规则。一次性导入成千上万条遗留告警，只会让团队把所有警告静音。更实际的策略是建立基线，要求新代码不引入新的高严重度问题；对每个抑制项写明原因、责任人和复查条件。

静态分析不能替代单元测试、硬件测试和代码审查，但它能让这些更昂贵的环节少花时间在明显错误上。

参考：Cppcheck