Checkmarx增量扫描不生效，表面看是扫描没变快，实质多半是基线分支没对齐、前置全量扫描缺失、或分支增量开关没有打开，导致系统只能按全量逻辑运行。把扫描类型、基线分支、分支增量开关三件事核对清楚，再去看引擎侧报错与增量缓存文件，通常能把问题定位到一个具体配置点或一次缺失的基线扫描。

　　一、Checkmarx增量扫描不生效

　　增量扫描在Checkmarx里属于SAST能力，机制是只扫描相对上一次全量扫描发生变化的代码及其关联闭包，因此没有可用的全量基线时，增量要么不会触发，要么会退回全量。你按下面顺序排查，会比反复重跑更快。

　　1、先在扫描列表确认本次到底跑的是Full还是Incremental

　　进入项目后打开【Scans】或对应扫描历史页，查看每一次扫描的【Scan Type】字段，确认显示的是【Full Scan】还是【Incremental Scan】；如果页面一直显示全量，先不要改代码，先去补基线与分支配置。

　　2、确认该项目是否已经有一次可用的全量基线扫描

　　增量扫描依赖上一次全量扫描的基线，且增量变化会在多次增量中累积，长期只跑增量会出现质量与速度的权衡问题；实际落地时建议先在主干分支至少跑一次全量，再在后续变更上跑增量，并周期性补一次全量回收基线。

　　3、在Checkmarx One检查项目是否启用了增量触发规则

　　如果你用的是Checkmarx One，进入【Project Settings】→【Rules】为SAST扫描创建规则，明确选择增量扫描作为默认或可选项，并确认发起扫描时没有把增量选项覆盖掉；手工触发扫描时也要在发起界面勾选【Incremental scan】才会以增量方式执行。

　　4、核对分支增量开关是否打开，避免只有主干能增量

　　如果你在主干能跑增量，但feature分支或PR永远跑全量，重点检查项目级配置scan.config.sast.incrementalInBranch是否为true，官方说明该能力默认是false，默认只对主干做增量，开启后才会在分支或PR上更倾向用增量跑。

　　5、遇到增量直接失败要把缓存与权限问题单独拎出来查

　　如果扫描类型显示为Incremental但很快失败，优先查看是否有增量依赖文件缺失或不可读的报错线索，例如CxSAST侧曾有因CxSRC中MethodMapping.zip缺失或无效导致增量失败的案例，常见诱因包括数据损坏或权限问题；这类问题不是调整分支就能修，需要先把引擎侧文件与权限修好再重跑。

　　6、确认你期望的增量效果是否被变更规模抵消

　　增量扫描只覆盖变更及闭包，若一次提交变更范围过大或触发闭包扩大，体感上可能接近全量；这时更有效的做法是把大改拆成多次小改，让增量能真正缩小扫描面，同时在合并到主干前再跑一次全量作为发布基线。

　　把扫描类型从结果页先钉死，再去补全量基线与分支增量开关，通常就能解释为什么增量不生效，以及该补哪一次全量才会恢复增量逻辑。

　　二、Checkmarx分支策略与基线怎么核对

　　分支策略核对的目标是让增量“有参照物”，让缺陷对比“有基线口径”。你需要同时核对两层含义，一层是增量扫描对比的基线分支，另一层是你们在CI里对不同分支采用全量还是增量的节奏。

　　1、把主干分支固定为唯一基线分支并写进项目配置

　　在Checkmarx One的SAST配置中，scan.config.sast.baseBranch用于指定增量扫描的基线分支，建议固定为你们的主干分支名，例如main或master，避免不同人用不同基线导致同一分支增量行为不一致。

　　2、核对分支命名与平台记录是否一致，避免基线分支找不到

　　在CI里实际分支名、仓库远端分支名、Checkmarx项目里的分支识别名要一致，尤其是有前缀或分组的分支命名；如果baseBranch填写的分支在仓库里不存在或被重命名，增量会退回全量或直接无法按预期比对。

　　3、把分支扫描节奏做成硬规则并落到流水线

　　建议把策略定成主干定期全量，功能分支与PR默认增量，且在连续若干次增量后强制插入一次全量；Jenkins侧插件也明确提示增量更快但随着时间会变得不够准确，因此需要定期执行全量扫描回收基线。

　　4、在项目配置里确认增量规则是否允许被单次扫描覆盖

　　如果你们允许开发在单次扫描里选择全量或增量，要在项目规则中明确是否允许覆盖，并在流水线参数里固化默认值，避免有人手工勾选导致同一分支今天增量明天全量，趋势与对比口径失真。

　　5、用一次对照扫描验证基线是否生效

　　在主干先跑一次全量作为基线，再在同一仓库的一个小改分支跑一次增量，回到扫描列表确认Scan Type确实切换为Incremental，并观察扫描时长与扫描范围是否缩小；这一步能把配置正确与否快速验证出来。

　　把baseBranch与incrementalInBranch两项配置对齐到你们的分支节奏，再用扫描列表的Scan Type做结果验收，分支策略与基线口径就能稳定下来。

　　三、Checkmarx增量扫描复现与修复闭环

　　把问题修掉不难，难的是让它下次不再复发。建议把复现、修复、验收、归档四步做成固定闭环，后续无论换人还是换流水线都能快速回到同一口径。

　　1、固化一套最小复现用例

　　准备一个小变更分支，仅改动少量文件，先在主干跑全量，再在该分支跑增量，用扫描列表确认类型与耗时差异，这套用例每次升级配置后都能用来验收增量是否仍生效。

　　2、把关键配置项做成可审计清单

　　把scan.config.sast.baseBranch与scan.config.sast.incrementalInBranch的当前值记录在项目配置台账里，并写清对应的主干分支名与分支扫描规则，避免出现配置改过但没人知道是谁改的情况。

　　3、把全量基线补跑机制写进发布节奏

　　规定每次里程碑或固定周期必须跑一次主干全量，作为增量的基线刷新点，并把该次全量扫描编号与时间点纳入发布归档；这样增量累积导致的偏差风险有明确回收点。

　　4、遇到增量失败先看引擎侧依赖文件与权限再看代码

　　一旦出现增量类型正确但执行失败，先按错误日志排查增量依赖文件缺失或无效与权限问题，再决定是否需要重建扫描缓存或补跑全量，不要直接把问题归因到代码仓库。

　　把增量扫描可复现用例、关键配置台账、周期全量基线、失败优先排查顺序这四件事固定下来，增量不生效的问题就能从偶发故障变成可控流程。

　　总结

　　Checkmarx增量扫描不生效时，先用扫描列表确认Scan Type，再补齐主干全量基线并核对是否启用了分支增量开关；Checkmarx分支策略与基线核对时，抓住baseBranch与incrementalInBranch两项配置，把主干全量与分支增量的节奏写入流水线并定期插入全量回收基线。把复现用例与配置台账固化为闭环，后续升级与复评也能稳定复现同一口径。