项目多次迭代后，相似的校验、转换、异常处理和接口调用可能分散在不同文件中。代码虽然还能运行，但后续修改同一条规则时，开发人员往往要同时处理多个位置，漏改一处就可能造成逻辑不一致。弄清SonarQube重复代码怎么查看SonarQube重复代码比例过高怎么降低，可以先找到重复集中的文件，再根据业务关系完成重构和验证。

SonarQube覆盖率报告怎么导入SonarQube覆盖率数据显示为空怎么办，很多团队在把代码质量平台搭起来以后，都会撞上这个问题。SonarQube这个工具自己是不会去生成覆盖率报告的，那串数据得先让JaCoCo、LCOV、coverage.py、dotnet-coverage或者gcov这类外部的测试覆盖率工具给跑出来，然后扫描器在分析的那一步，再把它们读到SonarQube里头，最后才在页面上亮出来。说白了，SonarQube干的活儿是接住这些数据然后展示出来，它可不替你跑测试，也不替你往外头吐覆盖率文件。

在SonarQube里面，扫描项目要怎么去配置，还有扫描的时候那些参数要是漏掉了、没给填上，会对最后出来的结果带来什么样的影响，这一块主要还是得去看项目用的是哪一种构建的方式，还有扫出来的结果要不要把分支、覆盖率，还有质量门禁这些个东西都给接进来。在SonarQube里头，那些拿来分析用的参数，一般都是照着sonar.这么一种样子去写的，有一部分参数，是能够在项目里面给写到一个配置文件里面去的，也可以通过命令行的方式，或者在CI的脚本里面，把它给传进去。

在代码扫描刚刚落地的时候，有两个问题是挺常碰到的，一个是SonarQube扫出来的问题，到底要怎么去分配给具体的人来处理，另一个是，这些问题它的状态变来变去，又要怎么去管，扫描出来的结果一多，要是没有个明确的负责人，那些问题就会长时间地挂在列表里面；可要是大家随便地就把状态给改成了已接受，或者是误报，那到了后面，再去搞质量门禁、版本复盘，还有审计说明的时候，就会很难说得清楚了。SonarQube在分析的时候，它会试着把新发现的问题，自动分配给，最后改过那一行代码的人，但这有个前提，就是代码提交时候用的那个账号，得能跟SonarQube里面的用户，关联得上；要是关联不上，那它就会去用项目里设好的那个默认处理人。

做SonarQube权限管理时，最容易乱的地方，不是按钮找不到，而是把全局权限、项目权限和令牌管理混成了一层。SonarSource官方文档把这条线分得很清楚，全局权限在【Administration】【Security】【Global Permissions】里管理，项目相关权限更多通过权限模板和项目级权限页来落地；而Token又是另一条独立链路，既有用户自己生成和轮换的分析令牌，也有管理员代用户生成或撤销的用户令牌。换句话说，权限和Token虽然都在安全域里，但真正稳的做法是分层治理。

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

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

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

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

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