分支合入主干前必须自动触发静态扫描并阻断不通过合并，而非仅扫master；需按分支类型差异化配置规则、精准排除路径、人工聚焦中高危问题复核，并确保扫描结果与提交强绑定、责任可追溯。
分支合入主干前做静态代码扫描，不是“锦上添花”，而是防止垃圾代码、高危漏洞、低级缺陷流入主干的必要卡点。它必须在 MR/PR 创建后自动触发，且扫描不通过应直接阻断合并，不能靠人工“自觉补救”。
为什么不能只扫 master 分支
只在 master 上扫描，等于把问题留到集成阶段才发现：修复成本翻倍、责任归属模糊、CI 流水线频繁失败、甚至带病发布。真实项目中，feature/xxx 或 bugfix/yyy 分支里已经存在硬编码密钥、SQL 拼接、未校验的用户输入——这些本该在提交时就被拦住。
- 扫描滞后 = 问题扩散：一个分支引入的空指针隐患，可能被其他分支基于它继续开发，形成连锁风险
- 人工补扫不可靠：开发者忘记手动触发、跳过提示、或误判“这个警告不重要”
- 工具报告脱离上下文：等合并到
master再看 SonarQube 报告，已无法精准定位是哪次提交引入的问题
GitLab / GitHub 上怎么让扫描自动绑定 MR/PR
关键不是“装个插件”，而是让扫描结果作为 CI 状态直接出现在 MR/PR 页面顶部，并设为必过项。以 GitLab + Jenkins + SonarQube 为例：
-
multiBranch Pipeline必须启用，且每个功能分支根目录下要有Jenkinsfile，否则 Jenkins 不识别分支变更 -
Jenkinsfile中需显式调用sonar-scanner，并传入参数-Dsonar.branch.name=${env.GIT_BRANCH}，否则所有分支扫描结果会混在master视图里 - GitLab 侧需在
Settings > Merge Requests > Approvals中勾选 “Require at least one approval from a group member”，并在CI/CD > General Pipelines开启 “Pipelines for merge requests” - 扫描失败时，Jenkins job 必须返回非零退出码（如
exit 1），否则 GitLab 仍显示 “passed”，起不到拦截作用
扫描策略要按分支类型差异化配置
不是所有分支都该跑全量规则。盲目开启全部检查项会导致误报泛滥、开发抵触，最终形同虚设。
-
feature/*分支：启用核心安全规则（如硬编码凭证、XXE、SQL 注入模式）、基础质量规则（空指针解引用、资源未释放），禁用复杂圈复杂度或重复率检测——新功能还在快速迭代，过度约束反而拖慢节奏 -
release/*或hotfix/*分支：强制开启所有高危 + 中危规则，且设置sonar.qualitygate.wait=true，确保质量门禁通过才允许合并 - 排除路径要写准：
**/test/**、**/mock/**、**/generated-sources/**必须加入sonar.exclusions，否则测试代码或 Lombok 编译产物会触发大量误报
人工复核环节不能省，但得聚焦重点
工具扫出的 80% 是低危或误报，但剩下那 20% 的中高危问题，往往藏在业务逻辑深处——比如鉴权绕过、金额校验缺失、幂等性漏洞。这些必须由人盯。
- MR/PR 描述里必须包含本次变更影响的模块清单（如 “修改了
PaymentService#doPay()和OrderController”），否则 Reviewer 无法快速定位扫描告警上下文 - 对
sonarqube标记为 “Blocker” 或 “Critical” 的问题，要求提交者在 MR 评论中逐条说明：已修复 / 属于误报（附理由）/ 暂不处理（需注明规避方案和后续跟进 Issue） - 支付、风控、用户资料等敏感模块的 MR，必须由至少一名非提交者 + 一名资深开发双签——不能只走形式点 “Approve”
真正卡住主干的，从来不是工具本身，而是扫描结果是否可追溯、是否与具体提交强绑定、是否有人对高危问题负起确认责任。漏掉任意一环，分支扫描就退化成“电子台账”。
