MISRA规则库的维护以及升级后对历史问题的处理，不能仅仅看作是去工具里面打开一组规则。需要长时间去管理的东西，还有MISRA的版本、工具的版本、规则跟规则之间怎么对应、编译的环境、项目里面做过哪些裁剪、严重等级是如何设定的，还有那些偏离了规则的记录。规则库在升级之后，规则的编号、适用的条件，还有工具具体实现的方式，都是有可能发生变化的，要是直接就拿新的规则去扫描老的代码，历史问题就很容易被重新统计一次，项目质量变化的趋势也就会跟着突然变得不真实。MISRA C:2025现在是MISRA C的现行版本，它是在原来版本的基础上做出来的增量更新，但是合规、偏离还有过程管理这些事情，还是应该按照一个统一的框架来执行。

　　一、MISRA规则库怎么维护

　　维护想要达到的目的，并不是叫工具里面的开关变得越来越多，而是要让每一次扫描都能够把“按照什么标准、在什么样的环境下面、检查了哪些代码”给说明白。这些信息要是没有固定下来，同一套源代码在不同的电脑上，扫出来的结果就很有可能完全不一样。

　　1、明确规则库基线

　　在项目刚开始启动的时候，就应该去建一份【MISRA规则基线清单】，把项目采用的标准是哪一个版本、语言是哪一个版本、规则分成了哪些类别、哪些规则被裁剪掉了，还有从哪一天开始正式生效，都记在里头。基线一旦确定下来，就不要因为工具版本升级了，就自己动去换成厂家给的那套默认规则。工具里面那些名字一样的“MISRA规则包”，实际对应的可能是不同的版本或者修订状态，项目应当先去把合同、安全计划还有开发流程里面的要求都确认好，然后再来决定是继续用MISRA C:2012，还是转到MISRA C:2025，或者别的规则体系。

　　2、区分标准规则与项目规则

　　MISRA规则是用来对语言的使用做约束的，但是企业里面往往还会自己加上一些命名的规范、复杂度的限制，还有禁止使用的接口这些要求。这两种问题虽然可以在同一个工具里头查，但是在出报告的时候，最好还是分开来统计，要不然企业内部那些格式上的问题一多起来，就会把真正需要去做合规判定的MISRA违规给盖住，开发人员也容易觉得，所有的告警全都得按一个办法去处理。

　　3、固定扫描环境和规则映射

　　每一次在正式发布以前，都应当去核对一下【静态分析工具版本】、【编译器配置】、【规则映射表】和【检查范围】，看它们是不是还跟基线对得上。像宏定义、头文件的路径、目标是哪一款处理器，还有编译的选项，这些要是有了变化，工具看到的代码也就跟着变了，哪怕规则库本身什么都没动，告警的数量也还是会忽多忽少。扫描的配置应该放到版本管理里面去，不能只留一份最后的报告，却找不到当时扫描用的到底是哪套规则和构建环境。

　　二、MISRA规则库升级后历史问题怎么处理

　　规则升完级以后，最怕的一个动作，就是直接拿新的扫描结果去把旧的给盖掉。历史问题一下子变得很多，并不一定就是代码质量往下掉了；问题突然少了一大片，也不等于代码已经修好了。得先把规则变了的和代码变了的这两件事给分开，数据才有办法去解释。

　　1、先完成新旧规则映射

　　在升级以前，应当先去理出来一份【新旧规则映射表】，把哪些规则是接着留用的、哪些是新加进来的、哪些是删掉了的，还有编号是怎么变的、分类是怎么调的，都在里头标清楚。做这个对应的时候，不能光去对编号，还要去看规则的意思还有工具检查的范围是不是也变了。有些规则编号看着还是原来的，但适用的条件已经改过了；还有些规则被拆开了，一条老的告警可能会变成好几条新的告警。先把这种对应关系建起来，后面才好去断那些历史的状态能不能接着往下用。

　　2、不要把全部告警算作新增问题

　　头一回用新的规则库去扫描的时候，应当单独去建一个迁移的基线，然后把扫出来的结果分成历史就有的、升级才多出来的、代码改动才加进去的，还有没有办法自动对应上的这么几类。升级多出来的那些问题，可以放到一个专门治理的工作计划里面去，但不大适合在很短的时间内就全都加进当前版本的门禁里，不然团队一下子就会背上好多跟这次代码改动没关系的旧问题。

　　3、重新确认已关闭问题

　　对那些已经标成了误报、偏离，或者是不适用的历史问题，不能只是把原来的状态原样搬过来。要重新去看一看当初判定的依据，放到新规则的底下，还站不站得住。要是规则的意思没怎么变，原来的记录就可以接着用；但要是检查的范围或者风险的解释变了，那就得再评一次。MISRA的合规框架，是要求对偏离和不适用的情况把有结构的依据留下来，不能光靠着工具里面那个关闭的按钮，就把结论给定了。

　　三、MISRA规则升级怎么保持审计连续性

　　规则的升级，经常是发生在项目已经做到中间的那个时候，代码、报告和偏离的记录都已经攒下一些了。要是处理得不好，升级前跟升级后的数据就会变成两套谁也不挨着谁的结果，等到评审的时候，就很难把一个问题是什么时候出来的、又是因为什么才没了的，给别人讲清楚。

　　1、冻结升级前的最终状态

　　在切换规则库之前，应当把【升级前基线报告】给保存好，同时把源代码的版本、规则的配置、还没关掉的问题，还有偏离的记录，一块儿给冻住。留这份基线不是为了一直用旧规则，而是为了让迁移以后的结果有个能拿出来比的参照。升级过后要是数量变化很大，就可以回到同一份源代码上去比，免得把代码提交带来的变化跟规则调整带来的变化搅在一起。

　　2、保留问题身份和处理依据

　　能够认出来是同一个问题的历史告警，就应该尽量把负责人、在哪个版本发现的、处理到了什么程度，还有评审的记录都给保住。工具内部的那个ID要是变了，可以通过文件、函数、代码的位置，还有规则映射，再去把它们串起来。确实对不上的那些问题，就得老老实实地记成是迁移才多出来的新记录，不能随随便便就去合并，免得后面想往回追的时候，连从哪来的都找不到。

　　3、分阶段调整质量门禁

　　新规则库刚用起来的时候，可以先只对新增的代码把门禁拉满，对老代码就先采取不继续变差，或者是分批去清的办法。等到新规则下面的误报、工具的配置，还有大家的理解都比较稳了之后，再一点一点把强制检查的范围放大。这样既能管住新问题，也不至于因为一次规则升级，搞得整个项目长时间通不过构建。

　　总结

　　MISRA规则库怎么维护MISRA规则库升级后历史问题怎么处理，要紧的地方是把规则的版本、工具的配置、编译的环境，还有偏离的管理，都放在同一个基线里面去管起来。升级之前得先把旧的结果冻住，升级之后要先去做规则映射，用同一版源码再扫一遍，然后把历史就有的、规则升级带来的和代码改动带来的问题给分开。已经关闭的状态既不能照搬，也不该全部推倒重来。把问题的身份、处理的根据，还有版本之间的关系都保留好，MISRA扫描出来的结果才能连着把代码质量的变化反映出来，而不是每回规则库一变动，就又从零开始去统计。