SonarQube的Pull Request分析用于检查本次代码变更引入的新问题，并把质量门结果与代码评审流程结合起来。它和普通分支分析并不是同一种任务：Pull Request分析需要明确源分支、目标分支以及PR标识，同时依赖CI流水线触发。处理“SonarQube怎么配置Pull Request分析，SonarQube Pull Request分析结果不显示如何排查”时，应先确认分析任务确实被识别为Pull Request，再判断问题出在扫描提交、后台处理还是DevOps平台展示环节。

　　一、SonarQube怎么配置Pull Request分析

　　SonarQube Server的Pull Request分析通常由CI流水线触发。受支持的CI环境能够自动识别部分Pull Request参数；自定义流水线或无法自动识别的环境，则需要手动传入相关参数。

　　1、先确认项目具备Pull Request分析条件

　　①查看当前SonarQube Server版本和版本类型，确认项目能够使用【Pull Request分析】能力。SonarQube Server当前提供Developer、Enterprise和Data Center等版本，Pull Request相关DevOps集成功能从Developer Edition开始提供。

　　②先完成目标分支的一次正常分析，例如PR准备合并到main，就先确保main已有有效分析结果。这样SonarQube才能更准确地判断PR相对于目标分支新增了哪些问题。

　　③确认SonarScanner已经集成到实际处理Pull Request事件的CI Job中，而不是只在main分支推送后执行。

　　④检查PR创建或更新代码后，对应流水线能够自动启动扫描。

　　2、手动设置Pull Request参数

　　如果CI无法自动识别Pull Request，需要给Scanner提供三个关键参数。SonarQube当前文档仍使用【sonar.pullrequest.key】、【sonar.pullrequest.branch】和【sonar.pullrequest.base】描述PR身份和分支关系。

　　例如：

　　sonar.pullrequest.key=125

　　sonar.pullrequest.branch=feature/login

　　sonar.pullrequest.base=main

　　①【sonar.pullrequest.key】填写当前Pull Request的唯一标识。

　　②【sonar.pullrequest.branch】填写包含本次修改的源分支。

　　③【sonar.pullrequest.base】填写准备合并到的目标分支。

　　④不要同时把当前任务配置成普通【分支分析】。如果流水线错误传入分支参数，扫描结果可能进入普通分支，而不是显示在Pull Request下面。

　　GitHub Actions、GitLab CI/CD等受支持环境可以由SonarScanner自动识别分支或Pull Request，因此这类环境通常不需要手工重复指定参数。

　　3、配置DevOps平台集成

　　如果希望分析结果直接显示在GitHub、GitLab、Azure DevOps或Bitbucket的PR页面，还需要完成SonarQube项目与对应DevOps仓库的绑定。

　　①检查项目是否绑定到正确的【Repository】。

　　②核对SonarQube使用的访问令牌或应用权限。

　　③确认当前仓库和Pull Request属于已经绑定的项目。

　　④先在SonarQube项目内部确认PR分析存在，再判断外部PR页面是否成功显示质量门结果。

　　二、Pull Request分析结果不显示如何排查

　　出现“CI显示扫描成功，但SonarQube找不到PR”的情况时，首先判断结果有没有被提交到正确的分析类型。

　　1、检查Scanner日志中的分析参数

　　①打开当前Pull Request对应的CI日志。

　　②检查Scanner识别到的【Pull Request key】【source branch】和【target branch】。

　　③如果日志只显示普通分支名称，没有PR标识，说明这次执行很可能被识别成了【分支分析】。

　　④自定义CI中发现自动检测失败时，显式传入三个Pull Request参数后重新执行。

　　⑤同时核对【sonar.projectKey】，避免结果被上传到另一个SonarQube项目。

　　2、检查后台任务是否真正处理成功

　　Scanner最后出现EXECUTION SUCCESS，只表示扫描数据已经提交，并不代表服务器端报告已经完成处理。SonarQube需要通过后台任务处理分析报告，任务完成前结果不会显示在项目页面。

　　①进入项目的【Background Tasks】查看当前分析。

　　②状态为【Pending】时，等待服务器完成处理，并检查是否存在大量任务积压。

　　③状态为【Failed】时，打开任务详情查看实际错误原因。

　　④如果任务已经成功，再进入项目的Branches和Pull Requests区域查找对应PR。

　　⑤多次触发同一个PR时，根据提交时间核对最新任务，避免查看了旧分析记录。

　　3、检查目标分支和Git检出方式

　　①确认【sonar.pullrequest.base】与PR实际目标分支一致，例如不要把release误写成main。

　　②检查CI是否使用过度精简的Git检出方式，确保分析环境能够获得计算代码差异所需要的仓库信息。

　　③PR修改了代码却显示0个新问题时，先确认分析的提交SHA与当前PR最新提交一致。

　　④如果PR刚刚修改目标分支，也要重新检查流水线中保存的目标分支参数。

　　Pull Request分析只关注相对于目标分支引入的新代码问题，因此目标分支选择错误时，即使任务成功，分析范围也可能与实际PR不一致。

　　三、SonarQube有结果但PR页面没有显示怎么处理

　　SonarQube项目内部能够看到Pull Request，而GitHub、GitLab等页面没有状态或评论时，说明代码分析本身大概率已经完成，应把重点转向DevOps平台集成。

　　1、检查项目绑定和授权

　　①确认SonarQube项目绑定的是当前PR所在的【仓库】。

　　②检查用于集成的Token、App或Service Connection是否仍然有效。

　　③查看对应账号是否具有向Pull Request写入状态或检查结果的权限。

　　④企业迁移仓库、修改组织名称或重新创建项目后，应重新核对绑定关系。

　　2、区分“没有问题”和“没有分析”

　　Pull Request页面没有显示新Issue，并不一定代表分析失败。SonarQube的PR分析主要报告本次变更新引入的问题，并使用项目质量门中针对新代码的条件进行判断。

　　因此调试时应同时查看【PR是否存在】【Background Task是否成功】和【Quality Gate状态】，不要单纯根据Issue数量判断任务有没有执行。

　　总结

　　Pull Request分析是否正常，关键在于SonarQube能否准确识别一次代码变更与对应目标分支，并把服务器端分析结果正确关联到代码评审流程。结果不显示时，将扫描任务、后台处理和DevOps平台展示分层判断，通常比反复修改Scanner配置更容易定位问题。稳定的PR分析流程也有助于让质量门真正参与代码合并决策。如需进一步了解SonarQube Pull Request分析配置、结果展示异常与CI集成排查，欢迎联系咨询。