在SonarQube里，误报这回事到底要怎么去处理，还有已经给它标上了误报之后，审查的记录又该怎么留下来，不能简单地理解成“工具报了，可我觉得没事，点掉就算了”。SonarQube里面可以把问题标成False positive或是Accepted，False positive更对路的用法，是分析出来的结果确实弄错了，Accepted就更偏着“问题是有的，但现在先这么接受，后面再找时间弄”。这两个状态要是混着用，后面做质量审查的时候，就不容易说清楚了。

　　一、SonarQube误报问题怎么处理

　　处理那些被当成误报的东西以前，得先把问题整个看一遍，好多被我们说成误报的，其实是代码写得太绕了，规则没真正弄明白，或者项目那边配的规则跟当前这段代码的场景不合适，直接给它标上，虽然一时省事，可后面一旦遇到质量审计、客户评审或者安全检查，就会变成新的麻烦。

　　1、先看一下规则的说明

　　把问题详情打开，去看规则的说明、触发的位置、给的示例代码，还有建议的修复办法，这一步主要是为了弄懂软件到底为什么报这个问题，比方说有些规则表面看只是管代码风格的，其实它真正关心的是空指针、资源没释放、分支太复杂或者安全漏洞，只有确认了当前这段代码确实不满足规则背后的那些设定，或者规则没法理解项目的上下文，才好接着去判断它算不算误报。

　　2、优先想想能不能动手改

　　如果这个问题能靠一点小范围的重构，补上一些空值判断，把复杂的表达式拆开，调整一下变量的命名，或者把重复的逻辑减少一些，就能把它解决掉，那一般就不建议直接给它标成误报，误报这个标记，应该用在“工具判断不适用”的这种场景里，而不是拿来绕开正常的改代码。

　　3、把误报和接受区分开

　　对于真的是分析结果弄错了的问题，就可以把它标为False positive；对于团队确认问题确实存在，只是因为要考虑兼容性、那是历史代码短期内不好动、改动风险比较大这些原因，才暂时不去处理的情况，就更适合标成Accepted，SonarQube的文档里也说了，False positive是说分析结果被认为错误，Accepted是表示接受了这个问题的状态。

　　4、把标记的权限管一管

　　误报的标记，不要让所有开发人员都可以随便去操作，比较稳的办法是让负责人、做代码审核的人或者质量那块的人一起确认，免得项目里出现一大堆“个人感觉是误报”的标记，要不然时间长了，质量门禁看起来是通过了，但真正的问题可能被这些状态标签给盖住了。

　　二、SonarQube误报标记后审查记录怎么保留

　　误报标记加上了以后，要紧的是留下能被审查的记录，干审查的人不会只看状态，他们更想知道为什么这么判断、是谁确认过、以后规则或代码变了要不要重新看一看。

　　1、把标记的原因写清楚

　　在【Issue Comment】里面，要写明规则的编号、代码是在哪个位置、判成误报的原因还有处理结论，说明不能光丢一句“误报”“不需要改”，更好的写法是讲清楚为什么这个规则在当前代码上不适用，比如说这个变量在上游的地方已经校验过了、当前这条路径根本跑不到、底层的框架保证了返回值不会是空的，又或者这段代码是生成器生成的，没办法人工去改，SonarQube在标记False positive的时候，也会有一个状态变更的评论框，正好可以拿来补上这一类说明。

　　2、把代码的上下文留下来

　　审查记录里面，要能让人看到文件名、函数名、触发的那一行、规则名称，还有当时代码的逻辑，只留下一张问题列表的截图是不够的，因为后面代码一旦改动，别人可能就已经看不出当初为什么把它判断成误报了，实在需要的话，可以把关键的那几行代码、调用关系，还有上下游的限制条件，一起放进外部的评审单里。

　　3、跟外部的流程挂上钩

　　如果团队在用Jira、禅道、GitLab Review或者自己内部的质量系统，就可以把SonarQube里问题的编号跟外部的审查单互相关联起来，在SonarQube里只放一个简要的结论，在外部系统里放完整的分析、评审的意见、责任人还有批准记录，这样比把什么东西都堆在评论区里要更清楚。

　　三、误报记录后续怎么复查

　　误报不是标完就可以一直不管了，代码重构、规则升级、SonarQube的版本更新，或者底层框架换掉之后，原来那个判断可能就不再成立了，如果复查这个机制不搞起来，误报就会慢慢地变成一种历史包袱。

　　1、定期把误报的项筛出来

　　可以按照项目、模块、规则、负责人，把False positive和Accepted的问题过滤出来，隔一段时间集中复查一次，SonarQube支持把那些Accepted或者False positive状态的问题重新打开，这说明之前下的结论并不是确认一次就永远固定的。

　　2、把判断的口径统一下

　　要是同一条规则在好几个模块里面反反复复被标记成误报，就要去看是这条规则真的不适合这个项目，还是说代码的写法本身需要调整，数量很多的误报，不应该靠一条一条点掉去解决，必要的时候就要去调整Quality Profile，或者形成一个项目级别的处理说明。

　　3、避免拿误报去掩盖真实问题

　　误报的管理最怕的就是变成“把工具的告警全部清掉”的一种手段，真正站得住脚的误报，要有技术上的原因、代码的上下文，还有评审的记录；要是只是短时间内不想改，那就不要写成误报，状态要是用错了，后面的质量报告看着是好了一点，但是代码里面的风险其实一点都没少。

　　总结

　　SonarQube误报问题怎么处理，还有误报标记后审查记录怎么保留，可以按照“先看规则说明、再判断能不能整改、把False positive和Accepted区分开、补上审查的说明、定期去复查”这样一条思路来做，误报这个标记，不是用来跳过质量要求的，而是对于工具分析不适用的情况，做一次有依据的确认，记录里面要把规则、代码位置、原因、审批和复查的条件都留下来，后面再做审查的时候，才不会只剩下一个光秃秃的状态标签。