C/C++test静态分析怎么配置，C/C++test静态分析扫描范围如何设定，想把结果跑得准、跑得稳，核心是三件事：配置口径统一、构建信息齐全、扫描范围可控可复现。
一、C/C++test静态分析怎么配置
把C/C++test静态分析配置好，目标不是规则开得越多越好，而是让同一套配置在不同人电脑和CI里都能产出同样的告警类型、同样的证据链，方便复核与整改。
1、先选内置配置跑通，再复制为团队配置
（1）打开Test Configurations，先用Static Analysis或Flow Analysis相关内置配置跑一次小范围，确认能生成规则编号、文件路径、行号与问题描述；
（2）复制内置配置生成团队配置，给出固定名称并写入团队约定，后续只允许使用这一个配置名，避免每个人手里一套口径。
2、把规则集从能跑变成可执行
（1）进入团队配置的静态分析设置页，先按缺陷族启用你们最关心的部分，例如空指针、资源泄漏、越界、未初始化等，首轮控制在可处理的数量级；
（2）把严重度口径定死，例如高严重度必须修或给出偏离说明，中严重度允许延期但要有责任人，低严重度先统计再逐步治理，避免复核阶段反复争论；
（3）对明显不适用于当前代码基线的规则先关闭或降级，等存量收敛后再逐步加严，否则首轮容易直接把流程推崩.
3、补齐预处理与编译语义，减少扫不到和误报
（1）优先确认分析拿到的编译信息完整，例如编译数据库或等价的编译命令来源是否覆盖所有目标模块，否则会出现某些目录看似在工程里却完全不被分析；
（2）把宏定义、条件编译开关、包含路径补齐到工程属性或配置里，尤其是平台宏、特性开关、第三方头文件路径不一致时，告警会明显偏多或偏少；
（3）同一仓库多编译器或多标准并存时，把编译器类型、语言标准、关键编译参数与模块绑定，避免同一文件在不同语义下被解释成不同结果。
4、把抑制做成受控动作而不是临时手段
（1）只对确认无风险或属于受控例外的条目做抑制，抑制理由要可复核，避免把真实缺陷一并压下去；
（2）对高频噪音优先回到配置层面做规则参数或工程语义修正，抑制只处理少量确实无法通过配置解决的个例。
二、C/C++test静态分析扫描范围如何设定
扫描范围决定了告警量和整改节奏。范围太大就只剩噪音，范围太小又失去趋势意义。更稳妥的做法是先小后大，先把关键模块跑干净，再用固定规则把边界写死。
1、首轮用选中即范围，确保跑得动看得完
（1）在工程树中选中模块或目录后执行Run Test或Analyze，把扫描范围和负责人对齐，首轮只覆盖你们真正维护且近期改动频繁的目录；
（2）把第三方库目录、自动生成代码目录、临时导入目录先排除，避免首轮告警量失控导致团队失去耐心。
2、用包含与排除把边界固化为规则
（1）在CI或命令行执行入口里配置include与exclude，include用于限定只扫哪些路径，exclude用于在限定范围内再剔除不需要的目录或文件模式；
（2）把include与exclude写进流水线脚本或集中配置文件，禁止个人临时改范围，这样同一提交在不同Runner上结果才可复现。
3、范围设了却扫不到，优先回头核对构建信息
（1）如果include覆盖了目录但结果仍不出现该目录文件，优先检查这些源文件是否真的进入编译命令集合，静态分析通常以此决定分析对象；
（2）如果工程是多目标构建，确认每个目标都生成了对应的编译信息，否则容易只扫到主目标而漏掉工具链或测试目标。
4、用基线把存量与增量拆开，范围才能扩得动
（1）首次全量扫描后建立基线，把存量告警作为技术债按迭代清理；
（2）门禁优先卡新增告警，先把趋势稳住，再按模块逐步扩大扫描范围，避免一次性全仓库门禁导致大量阻塞。
三、C/C++test静态分析配置与范围如何固化到CI门禁
配置和范围只有落到同一条流水线并长期稳定运行，C/C++test静态分析才算真正起效。要重点防三类漂移：配置名漂移、构建信息漂移、范围边界漂移。
1、固定配置名与执行入口
（1）CI统一使用同一执行入口与同一配置名运行静态分析，团队配置随仓库版本管理，确保任何Runner拉取后都能跑出同样口径；
（2）报告与告警清单作为流水线产物留存，便于回溯每次提交新增了哪些告警、修复关闭了哪些告警。
2、门禁规则按新增必拦存量可管拆两层
（1）第一层只拦新增高严重度告警，要求必须修或提交偏离说明并走评审；
（2）第二层统计存量收敛趋势，用数据驱动规则加严与范围扩张节奏，避免拍脑袋推进。
总结
C/C++test静态分析怎么配置，C/C++test静态分析扫描范围如何设定，先把团队配置与构建语义固化，再用包含排除与基线控制扫描范围，最后把同一配置名同一范围写进CI门禁，就能让结果稳定可复现、告警可执行可收敛。
