我完全懂你的困惑——就像文档里那个厨房积水的比喻，明明代码没动（没新增积水），结果质量门却因为40%的泄漏周期覆盖率要求失败了，这确实让人摸不着头脑！我之前帮团队解决过类似问题，也在社区见过不少用户遇到相同状况，给你梳理几个最可能的原因和解决思路：

• 泄漏周期的基准配置出了问题
  默认的泄漏周期是previous_version，但如果你的VSTS构建没有正确传递项目版本号，或者SonarQube的版本标签生成逻辑有问题，就会导致SonarQube误判了"初始分析"和"最新分析"的对比基准。比如两次构建的版本号被自动设成了不同值，SonarQube就会把它们当成两个不同的周期，哪怕代码完全一致，也会触发泄漏检查。
  你可以去SonarQube项目的 Administration > General Settings > Leak Period 里，把周期改成previous_analysis，这样就严格以上一次的分析结果作为基准，避免版本号带来的干扰。

• 覆盖率报告的生成或上传异常
  哪怕代码没改动，测试报告的生成、上传环节也可能出现波动。比如第一次分析时测试报告没完整上传，第二次传了全量报告，或者反过来，两次的覆盖率数据就会有差异，SonarQube就会判定为"泄漏"。
  你可以对比两次分析的覆盖率详情页，看看数据是否一致。同时检查VSTS构建中的SonarQube任务配置，确保测试报告路径（比如sonar.cs.vstest.reportsPaths针对C#项目）每次都能正确指向同一个测试结果文件，避免路径错误或者报告缺失。

• SonarQube的内部缓存或索引异常
  这种情况比较少见，但偶尔SonarQube的缓存会出现偏差，导致它没正确识别两次分析的代码一致性。你可以试试在SonarQube项目的Actions菜单里触发一次「重新分析」，或者联系管理员清理下项目的缓存数据，看看能不能解决。

我之前碰到的一个典型案例是：团队在VSTS构建里没固定版本号，每次构建的版本都是随机生成的，导致SonarQube每次都拿新的版本标签和旧版本对比，哪怕代码没动，也触发了泄漏周期的检查。改成previous_analysis的周期配置后，问题就直接解决了。

内容的提问来源于stack exchange，提问作者Franko_K