很多人一提到MISRA C，第一反应就是“把所有规则背下来”。可真到项目里，最容易出错的地方反而不是记不住编号，而是把规则内容、规则级别和项目执行要求混成了一件事。MISRA官方在《MISRA Compliance:2020》里把这件事讲得很清楚：每条guideline都会带一个MISRA category，也就是Mandatory、Required或Advisory，这个级别决定的不是规则“重不重要”这么简单，而是违反之后在合规上能不能被接受、要不要走正式偏离流程。

　　一、MISRA C规则怎么理解

　　先把“规则”这个词看清楚。MISRA官方把guideline作为总称，下面又分成directive和rule。directive更像需要结合流程、方法和证据去落实的指导项，rule则是定义更完整、更明确的语言限制。所以项目里说“我们按MISRA C做代码规范”，并不只是看静态分析工具扫了多少条rule，还包括对directive的执行方式、证据和约束边界有没有说清。

　　1、先看规则在限制什么

　　有些规则是在限制语法和语言用法，有些规则是在限制库函数、类型转换、控制流和未定义行为。理解MISRA C，不能只停在“这条要不要改”，而要先看它到底在防哪类风险。这样后面做偏离判断时，才不会把所有规则都当成同一类问题处理。

　　2、再看规则级别在说什么

　　MISRA category的作用，是规定违反这条guideline时项目可以怎么处理。它不是技术难度标签，也不是业务优先级标签，而是合规处理规则。也正因为这样，同样是两条代码问题，一条可能必须消除，另一条则可能在受控条件下接受偏离。

　　3、最后再看项目怎么执行

　　MISRA Compliance:2020还要求项目建立Guideline Enforcement Plan、Guideline Compliance Summary这类记录。换句话说，真正的MISRA C合规，不是“我们知道这条规则”，而是“我们能说清这条规则怎么检查、有没有违反、违反后怎么处理”。

　　二、MISRA C必选规则与建议规则怎么区分

　　这个问题最容易被说得太简单。很多人把Mandatory理解成“必须遵守”，把Advisory理解成“可以不管”，这样说并不准确。MISRA官方论坛和《MISRA Compliance:2020》的公开内容给出的边界更清楚：Mandatory guideline的违反不被允许；Required guideline的违反原则上不允许，但在有正式deviation的前提下可以接受；Advisory guideline仍然应当遵守，只是它的违反不一定需要正式deviation，但仍然需要被识别和审查。

　　1、Mandatory先看成不能带伤放过

　　Mandatory这一类不是“尽量满足”，而是违反后不能按普通偏离去消化。官方公开说明里还特别指出，原本属于Mandatory的guideline不能被重新降级，所以这一类最适合在项目里作为硬门槛来管。

　　2、Required要看正式偏离能不能成立

　　Required不是“比Mandatory轻一点所以无所谓”，而是“默认也不能违反，只是允许在受控条件下走正式deviation”。所以项目里真正需要花工夫的，往往不是把它简单归到“可放宽”，而是先判断偏离理由、使用场景和补充控制措施能不能站得住。

　　3、Advisory不是可做可不做

　　这一类最容易被低估。MISRA Compliance:2020的公开内容明确提到，保持为Advisory的guideline发生违反时，虽然不要求正式deviation，但仍然需要被识别。也就是说，它不是“可以忽略”，而是“不能像Mandatory和Required那样处理得那么重”。

　　4、项目里还可能出现重新分级

　　MISRA官方还给了GRP，也就是Guideline Re-categorization Plan。它允许项目在约定条件下把某些Required提高成Mandatory，或者把某些Advisory提高成Required，甚至在特定条件下Disapply。真正落地时，因此不能只背书上的原始级别，还要看项目自己的revised category。

　　三、MISRA C规则级别为什么不能背死

　　真正做项目时，最怕的不是规则多，而是把规则级别当成永远不变的标签。MISRA官方公开文档已经给了两个很现实的提醒：一是项目层可以通过GRP做重新分级，二是规范本身的技术更正也可能直接改规则类别。Technical Corrigendum 2就明确把Rule 13.6从Mandatory改成Required，又把Rule 17.5从Advisory改成Required。也就是说，你如果只凭一版旧表格去背级别，后面很容易把处理边界做错。

　　1、先看你项目采用的是哪一版基线

　　如果项目采用的是MISRA C:2012加TC2和后续修订，那你看的级别就应当按修订后的版本来，不该还停在更早的印象里。规则内容可能没大改，处理级别却可能已经变了。

　　2、再看项目有没有做重新分级

　　哪怕标准原始级别没变，项目自己也可能把某些Advisory提高成Required，或者把某些Required提高成Mandatory。真正评审代码时，更该看的往往是项目自己的GRP，而不是网上随手找的一张级别对照表。

　　3、最后把重点放回处理动作

　　说到底，区分Mandatory、Required、Advisory的意义，不是为了考试背分类，而是为了决定违反后怎么处理。你只要把“能不能违反、要不要deviation、项目有没有重新分级”这三件事弄清，规则级别这件事就不会再只是一个死记硬背的问题。

　　总结

　　MISRA C规则真正要理解的，不只是每条规则写了什么，还包括它在合规上属于哪一种category。Mandatory重点在于不能带伤接受，Required重点在于默认不允许但可在正式偏离下受控接受，Advisory则不是随便忽略，而是仍要识别和审查。到了项目里，再往前走一步，还要看当前采用的是哪一版规范、有没有技术更正、项目有没有做重新分级。把这些层次分开以后，MISRA C就不会再只是“背规则清单”，而会变成一套更容易执行和落地的合规逻辑。