在Checkmarx里改规则后看不到效果，很多时候并不是规则源码本身没保存，而是规则虽然改了，却没有真正进入这次扫描的生效链路。按Checkmarx官方公开文档来看，这条链路至少有三层：先在Query Editor里改查询，再把查询放进Preset，最后让项目扫描时真正使用这个Preset。再往后，如果你跑的是增量扫描，或者项目在“无代码变化”场景下直接复用了上次结果，表面上也会很像“规则改完没生效”。所以这类问题更稳的排查方式，不是只盯着查询源码，而是把规则、Preset、项目绑定和扫描方式连起来看。

　　一、Checkmarx规则改完不生效

　　规则改完不生效时，不要先怀疑平台缓存。更常见的情况，是规则虽然存在，但当前项目根本没扫到它。Checkmarx官方文档明确写到，SAST的扫描必须使用Preset，而且Preset本质上就是一组会参与扫描的查询集合。如果规则不在当前项目使用的Preset里，或者项目压根绑定的是另一套Preset，那么你在Query Editor里改得再多，这次扫描也不会体现出来。

　　1、先确认改的是项目真正使用的查询

　　官方说明，Query Editor可以从项目面板进入，也可以独立打开；从项目面板进入时，它会先对该项目做一次关联扫描，然后再让你操作。更稳的做法，是优先从目标项目的SAST区域进入Query Editor，而不是在独立界面里改完以后默认以为所有项目都会跟着变。

　　2、再确认规则有没有进当前Preset

　　Checkmarx官方对Preset的定义很直接：Preset是扫描时真正被选中的查询集合，而且SAST必须有Preset。也就是说，规则源码改好了，只是第一步；真正让扫描用上它，还要到Preset Manager里确认这条查询已经被勾进当前Preset，并且已经保存。

　　3、再确认项目绑的是不是这套Preset

　　官方文档还说明，Preset列表里会显示Associated Projects，也就是哪些项目正在用这套Preset。排查时不要只看Preset本身有没有保存，还要回头看目标项目到底是不是绑定了这套Preset。很多“改了不生效”，其实只是项目还挂在旧Preset上。

　　4、增量扫描下先不要急着认定规则没生效

　　Checkmarx One官方文档写得很清楚，SAST增量扫描只扫描变更文件和它们附近的闭包文件，结果再和上一次完整扫描结果合并展示。也就是说，如果你改了查询，但这次扫描本身还是增量，而且目标结果又落在未重扫的区域，表面看起来就会像“规则没生效”。这时候更稳的是先做一次完整扫描，再判断规则效果。

　　二、Checkmarx规则发布与缓存怎么排查

　　“发布与缓存”这件事，在Checkmarx里更准确地说，不是单纯查缓存文件，而是查规则修改、Preset变更和项目扫描之间有没有被旧结果复用。官方文档已经给出了一条很关键的线：当项目没有代码变化时，系统原本可能会跳过扫描并复制上一次结果；但如果项目关联的Preset里有查询新增、删除或修改，这类环境变化本身就应该触发重新扫描。也就是说，所谓“缓存没更新”，很多时候其实是在查项目有没有因为非代码变化而被强制重扫。

　　1、先看当前是不是无代码变化场景

　　官方文档明确说明，在计划任务或API触发的扫描里，如果没有检测到代码变化，系统可能会直接跳过扫描并复制上次结果。对规则发布后的验证来说，这一步很关键，因为你如果刚好在无代码变化条件下看结果，就很容易把“复用旧结果”误判成“规则没生效”。

　　2、再看查询或Preset变更有没有触发强制扫描

　　Checkmarx官方还写得很明确，以下环境变化会触发完整扫描：与项目关联的Preset中新增或删除查询、修改查询、修改项目的排除规则、修改项目扫描配置，以及引擎包升级。也就是说，如果你的环境支持这一机制，规则改动本身就应该被识别成需要强制重扫的变化，而不该继续沿用旧结果。

　　3、增量扫描验证规则时优先改成完整扫描

　　官方增量扫描文档说明，增量扫描始终建立在上一次完整扫描基础上，而且无代码变化逻辑、增量阈值和闭包文件机制都会影响结果呈现。实操里如果你现在的目标是验证规则是否真正生效，最稳的办法通常不是继续跑增量，而是先切回完整扫描。这样最容易排掉结果合并和旧基线带来的干扰。

　　4、日志要分成项目日志和系统日志两层看

　　如果你是Checkmarx One用户，官方文档说明可以在项目的Query Editor里通过右上角菜单下载scan logs的zip包，这一层更适合看当前项目扫描到底用了什么查询、跑到了哪一步。如果你是CxSAST这一类需要看系统级行为的环境，官方“环境变化强制扫描”文档还特别提到，JobsManager日志会打印因为配置变化而强制触发扫描的记录。这两层日志不要混着查。

　　三、Checkmarx先查规则还是先查扫描链路

　　真正把问题查顺，最怕的不是不会改规则，而是顺序反了。明明规则早就写对了，却一直在Query Editor里反复改；明明项目没绑定对应Preset，却在怀疑引擎缓存；明明只是增量扫描和无代码变化复用了旧结果，却一直以为发布失败。更稳的顺序通常是先看扫描链路，再回头看规则本身，这样最容易把问题收窄。这个判断和Checkmarx官方把Query Editor、Preset、项目扫描和环境变化触发机制分开说明的逻辑是一致的。

　　1、第一步先查项目扫描到底用了哪套Preset

　　因为Preset才是SAST真正会执行的查询集合。只要这一步没站稳，后面规则写得再精细，也没有实际落点。

　　2、第二步再查这次扫描是不是完整重扫

　　如果当前是增量扫描，或者无代码变化直接复用了旧结果，你看到的“没变化”本来就不一定说明规则失效。对规则验证来说，完整扫描的结论更有参考价值。

　　3、第三步最后再回头看规则源码和关联语言

　　当项目绑定、Preset和扫描方式都已经确认无误，再去查查询本身是不是写在正确语言下、是不是被保存到正确位置，这时排查效率才最高。官方Preset文档也强调了语言维度和查询勾选关系，说明这一层应该放在链路确认之后再看。

　　4、规则经常改动时，把验证动作固定下来

　　如果团队会频繁调规则，比较稳的方式不是每次手工点几下就结束，而是固定一套验证动作：改查询，查Preset，确认项目绑定，跑完整扫描，下载日志。这样后面出现“改了没生效”，你更容易知道是卡在规则、Preset还是扫描链路。这个做法虽然是实操建议，但它完全顺着官方给出的功能层级来的。

　　总结

　　Checkmarx里规则改完不生效，很多时候不是规则没保存，而是规则没有真正进到当前项目的扫描链路里。查这类问题时，先看规则是不是进了Preset，再看项目是不是绑了这套Preset，然后确认这次是不是完整重扫，而不是被增量扫描或无代码变化机制带回了旧结果。把这条顺序守住以后，“规则发布”和“缓存排查”这两个看起来很虚的问题，通常都会落到更具体、也更容易改的点上。