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

　　一、SonarQube扫描很慢

　　扫描慢时，先别急着加机器，更稳的做法是先把分析范围收干净。SonarSource官方的Analysis scope文档已经把入口写得很明确，源码和测试代码都可以通过`sonar.exclusions`、`sonar.inclusions`、`sonar.test.exclusions`、`sonar.test.inclusions`来控制；如果把不该扫的生成物、第三方目录、历史目录也一起扔进去，扫描时间自然会被拉长。

　　1、先缩分析范围

　　优先把生成代码、第三方依赖、大体积非目标目录排掉。范围一旦过大，后面的缓存和并发再怎么调，收益也会被摊薄。官方还提供了查看扫描上下文的方法，可以在项目的Background Tasks里打开Show SonarScanner Context，直接核对本次到底扫了哪些路径和排除了哪些路径。

　　2、再看是不是扫了不该扫的模块

　　如果你走的是Maven这类构建式扫描，官方文档说明可以用`sonar.skip`排除某些模块，也可以用构建参数只跑需要的模块。对大仓库来说，这一步通常比盲目提线程更有效。

　　3、再查语言侧前置条件

　　有些慢，不是慢在分析器本身，而是前置条件没满足导致反复重试或质量下降。比如Java分析要求正确提供`.class`文件，否则会报缺少字节码；GitHub Actions场景下，如果你用的是浅克隆，官方也提醒会触发blame和ref相关问题。虽然这类问题不一定直接表现成报错，但经常会把一次扫描拖得又慢又乱。

　　4、运行环境也别忽略

　　SonarScanner CLI官方文档明确不建议在扫描机上同时跑杀毒扫描，因为这会带来不可预测行为。对大项目来说，这种环境层干扰很容易直接反映成扫描时间异常。

　　二、SonarQube扫描缓存与并发怎么调

　　缓存和并发要分开调，因为它们不是一回事。官方增量分析文档说明，analysis cache默认会在分析前下载对应分支缓存，分析后再回写分支缓存；对分支分析，真正能明显缩短时间的语言主要是C、C++、Objective-C和COBOL，而对PR分析，Java、JavaScript、C#、VB.NET、TypeScript、Kotlin、PHP、Python等也能从目标分支缓存中获益。也就是说，先确认你的语言到底能不能从缓存里真正省时间，再决定要不要往并发上加力。

　　1、缓存先用默认机制

　　官方文档写得很明确，analysis cache默认启用，而且默认用服务器端存储。对大多数项目来说，先把主分支、长期分支和PR分析跑顺，让缓存自己积累起来，往往比一上来改存储方式更稳。

　　2、C家族要缓存更深时再看本地文件系统缓存

　　SonarSource对C、C++、Objective-C提供了更细的缓存控制，可以把`sonar.cfamily.analysisCache.mode`设为`fs`，再用`sonar.cfamily.analysisCache.path`指定缓存目录。官方同时也提醒，这种文件系统缓存配置更复杂，因为缓存生命周期要由CI自己管理，所以它更适合长生命周期分支或你确实需要精细控制缓存时再上。

　　3、C家族并发优先看`sonar.cfamily.threads`

　　官方文档说明，C家族分析器默认会尽量按机器逻辑CPU数并行，只有在自动识别不符合预期，或者你想故意给同机其他任务留资源时，才建议手动设置`sonar.cfamily.threads`。而且这个值不应超过可用逻辑CPU，超配不会加速，反而可能变慢。

　　4、Python和文本分析也有各自线程参数

　　Python分析器默认会使用可用核心的大约九成，最多到6个线程；需要手动调时，官方提供的是`sonar.python.analysis.threads`，也支持把并行分析直接关掉用于排查。文本和Secrets分析则走`sonar.text.threads`。这也说明，并发不是一个叫“全局线程数”的通用旋钮，而是按语言分析器分别控制。

　　5、缓存异常时再考虑禁用排查

　　如果你怀疑缓存本身让结果异常，官方文档提供了`sonar.analysisCache.enabled=false`来临时关闭analysis cache。这个动作更适合做定位问题时的对照，不适合作为常态配置，因为关掉以后扫描会回到从头全量分析。

　　三、SonarQube先看哪些项

　　真正要把扫描时间压下来，最省时间的办法不是一次改很多参数，而是先按顺序看。先看分析范围，再看缓存有没有真正命中，最后才看并发是不是需要手调。因为官方文档已经把这三层边界写得很清楚，范围决定要扫多少，缓存决定能不能少扫，并发决定同一批要扫的内容怎么分摊。

　　1、先看扫描上下文

　　先去Background Tasks里看Show SonarScanner Context，确认本次到底用了哪些参数、排除了哪些目录、有没有把不该扫的内容带进去。这个动作最适合排查“为什么这次突然慢很多”。

　　2、再看缓存命中逻辑

　　重点看当前是主分支、普通分支还是PR。因为官方对这三类场景的缓存来源写得很明确，分支分析用本分支缓存，PR分析优先用目标分支缓存，不存在缓存时才回退到主分支缓存。缓存逻辑没对上，调线程往往也救不了。

　　3、然后看语言插件本身

　　如果项目主要是C家族，就重点看`sonar.cfamily.analysisCache.mode`、`sonar.cfamily.analysisCache.path`、`sonar.cfamily.threads`和增量符号执行；如果主要是Python，就看`sonar.python.analysis.threads`和并行开关；如果文本与Secrets扫得多，就看`sonar.text.threads`。按语言拆开，比找一个所谓“总并发参数”更靠谱。

　　4、最后才看机器资源

　　如果范围已经收过、缓存也正常命中、线程参数也合理，扫描还是慢，再回头看CI机器的CPU、内存和同机任务竞争会更合适。官方对并发参数的说明本身就在强调一件事，线程不是越大越快，资源争抢严重时，过度并行只会拖慢。

　　总结

　　SonarQube扫描很慢，最先该做的通常不是盲目提并发，而是先把分析范围和扫描上下文看清。SonarQube扫描缓存与并发怎么调，关键则是先用好默认analysis cache，再按语言分析器去调对应线程参数，像C家族看`sonar.cfamily.threads`，Python看`sonar.python.analysis.threads`，文本分析看`sonar.text.threads`。把范围、缓存、并发这三层拆开处理，扫描时间通常会比一开始直接压机器资源更容易降下来。