SonarQube

很多团队一上来就先往`.gitlab-ci.yml`里塞扫描命令，结果跑是能跑，后面要么MR不出结果，要么质量门禁没法拦合并，要么分支和MR参数还互相打架。SonarQube官方文档把这条链路拆得很清楚，GitLab CI集成至少有三步，先在SonarQube里把项目建好并和GitLab关联，再把分析任务接进GitLab CI/CD，最后再让MR分析和质量门禁结果回写到GitLab。真正稳的做法，不是先写脚本，而是先把项目绑定、扫描入口和MR触发条件摆顺。

部署SonarQube时，先不要急着选安装包，更关键的是先把运行方式想清楚。SonarSource官方文档现在把这条线写得很明确，服务端部署主线就是先检查服务器要求和Java版本，再准备数据库，然后按ZIP或Docker方式完成基础安装；如果只是测试，可以先用内置H2，但生产环境不建议这样做，而且官方明确建议生产库与SonarQube主机分离部署。

SonarQube质量门禁不通过，先别直接翻全量Issue列表，最快的办法是先确认失败条件属于新代码还是全量代码，再沿着失败条件跳转到对应的证据页。因为质量门禁的每个条件都绑定到新代码或全量代码，两者口径不同，定位路径也不同。

很多人配置Webhook时，能看到扫描结果更新，却收不到回调通知，往往是回调地址填错位置，或回调其实发送了但被网络与鉴权拦住。处理这类问题的关键是先把回调地址填在正确层级，再用交付记录把每一次回调的状态码与错误信息对上，最后再回到网络与证书这类环境问题做针对性修复。SonarQube支持项目级与全局级两种Webhook，并且两者会同时触发，这一点经常被忽略。

同一个仓库里，重复度突然抬头，最怕的不是分数难看，而是团队马上陷入无差别重构，结果改了很多却没解释清楚为什么会升高。更稳的做法是先把跳变的起点和统计口径确认清楚，再把范围限定和新代码门禁立起来，让新增重复先止住，存量重复再按节奏消化，这样复盘和审计都站得住。

做SonarQube扫描时，很多人一看到失败就先去改项目配置，结果改了半天，真正的问题其实可能在令牌、服务器地址、证书、代理，或者服务器后台任务本身。Sonar官方文档把这件事拆得很清楚：分析参数里有一批必须在CI/CD主机上设置的基础项，分析失败时又要分别看Scanner侧和Server侧的日志；如果网络链路里还有代理、HTTPS或自签名证书，排查顺序还会再往网络层延伸。把这些层次分开看，扫描失败这件事通常会比一上来就反复重跑更容易收住。

SonarQube里与安全相关的告警，既有Vulnerability这类可被利用的漏洞，也有Security Hotspot这类需要人工复核的安全敏感点。处理时如果不先分清类型与口径，很容易把热点当漏洞硬修，或把真实漏洞当成可忽略项拖延。下面按“先处理再排序”的顺序，把日常可复用的操作路径写清楚。

在团队落地SonarQube时，很多规则看起来够用，但一到具体代码风格与合规要求，就会出现想加严某个阈值、想把某类问题单独拎出来、想让不同团队用不同口径的需求。要把这件事做稳，思路是先用规则模板快速生成可维护的自定义规则，再用质量配置文件也称为Quality Profile把规则集合分发到项目，并用备份与回滚把变更变成可追溯动作。

sonarQube升级后出现登录失败，常见不是账号本身突然失效，而是数据库迁移未完成、反向代理与服务器地址不一致、或外部认证接入在新版本下触发了回调与权限问题。排查时先把实例是否已完成迁移与索引重建确认清楚，再把登录链路与认证配置逐段拆开看日志，通常能把问题收敛到一两处可操作的点。

sonarQube里覆盖率一直是0，通常不是平台不会算，而是覆盖率报告没有被导入，或报告里记录的文件路径和本次扫描识别到的源码路径对不上。排查时先确认报告有没有生成，再确认扫描器能不能读到，最后再看映射口径是否一致，把这三步跑通，问题一般就能闭环定位。

SonarQube扫描慢，很多时候不是服务器本身有问题，而是把三类事情混在了一起，一类是分析范围太大，一类是缓存没有真正用起来，还有一类是并发开法和语言插件本身的机制没对上。SonarSource官方文档写得很清楚，增量分析里的analysis cache是按分支管理的，扫描前会先下载缓存，扫描后再按规则回写；但并发并不是一个所有语言通用的总开关，而是由不同语言分析器分别控制。也就是说，先分清你慢在范围、缓存，还是线程，后面才调得准。

很多团队把安全热点当成漏洞去清单式消灭，结果要么误修一堆本来就安全的写法，要么把真正的漏洞淹没在噪声里。围绕SonarQube安全热点怎么用，SonarQube安全热点与漏洞问题怎么区分，抓住一个原则就够了：热点先人工复核再定性，漏洞确认即刻修复并纳入门禁。

SonarQube的规则生效载体不是单条规则开关，而是质量配置文件也叫Quality Profile，按语言维度生效，再由项目绑定决定最终用哪一套。你要把规则配置做稳，顺序应当是先建规则集载体，再分配到项目，最后做变更后的生效核对与回滚预案，否则很容易出现改了规则但项目不生效的错觉。

sonarQube里扫描端显示执行成功，但平台侧一直Pending或后台任务持续排队，这类现象本质是Compute Engine没有把分析报告及时消费完，队列越堆越长就会连带影响质量门禁与看板刷新。处理时不要只盯着队列数量，而是先把是否存在卡住的单任务、是否为资源瓶颈、是否为并发配置不匹配这三类原因拆开，再按可操作的步骤逐项收敛。

分支页面能看到一次次分析记录，但【New Code】几乎不动，最常见的原因不是扫描没跑到，而是跑成了另一种分析类型，或分支参数没有真正生效，再加上新代码口径选得不贴合分支开发节奏。按下面顺序逐项核对，把入口、参数、生效结果三件事对齐，新代码通常就会恢复正常显示。

很多人装SonarQube时，前面把压缩包解开了，后面一启动就报错，于是第一反应是怀疑安装包有问题。其实SonarQube官方文档把安装链路写得很清楚，真正高频的失败点通常集中在三层，也就是Java版本不对、数据库配置没接好，以及Linux主机没有满足Elasticsearch启动前置条件。只要把这三层顺着排下来，大多数安装问题都能比较快收住。

SonarQube在网页里看趋势很方便，但到了里程碑评审、对外交付、审计留档，就需要把同一时间点的报告与数据“固化”为文件，并且能说清楚分支口径、筛选条件与拉取时间。否则很容易出现今天导出的数据和下周再看不一致，最后只能靠截图解释，证据强度不够。下面按导出与归档两条线，把操作路径与常见坑一次讲透。

同一套代码在sonarQube里突然“满屏告警”，多数不是代码质量一夜变差，而是规则口径、扫描范围、分支与新代码基线没有对齐，导致历史债与噪声一起涌进来。要把命中数量压到可治理的水平，关键是先把问题分层，只让团队当下要管的东西进入门禁，再把规则集按语言与团队成熟度分配到位，最后用一套例外管理把误报与可接受偏差收口。

sonarQube扫描后发现某些目录没出现在代码页面或度量里，通常不是被系统吞了，而是扫描范围口径不一致，常见表现是项目根目录不对、源目录未纳入、排除规则过宽、或报告里的路径无法映射到源码。把缺失目录定位清楚后，再去写排除通配符，才能避免一边修一边越排越多。

拉取请求装饰不显示，最常见的原因有三类：实例侧没有把DevOps平台集成配完整，项目侧没有绑定到正确的仓库配置，流水线侧没有把PR分析参数传给SonarScanner。处理时不要上来就重装或换插件，按实例设置、项目绑定、流水线参数三段把链路对齐，通常一次就能定位到缺口。