C++ Core Guidelines不能直接用于MCU项目，因其依赖标准库和运行时特性（如异常、RTTI、动态内存），而裸机/FreeRTOS环境通常禁用这些特性且资源受限；需裁剪规则，禁用涉及堆分配、异常、类型擦除等条款，保留零开销安全实践（如auto推导、constexpr、[[nodiscard]]），并补充对齐检查。
为什么不能直接套用C++ Core Guidelines到MCU项目
Core Guidelines设计目标是提升通用C++代码的安全性与可维护性，但IoT嵌入式场景下，std::vector、std::string、异常处理、RTTI、动态内存分配等默认推荐项会直接触发编译失败或运行时崩溃。例如在STM32F4（192KB RAM）上启用new操作符后，std::optional<int></int>可能隐式调用operator new，而你的链接脚本根本没预留堆空间。
关键矛盾点在于：Guidelines假设“有标准库+可控运行时”，而裸机或FreeRTOS环境往往只链接libgcc和libc_nano，且禁用-fexceptions和-frtti。
必须禁用的Guidelines规则（带编译器级强制）
以下规则若强行启用，会导致链接失败或不可预测行为，应在CMakeLists.txt中显式关闭：
-
ES.20（禁止裸指针）→ 改用gsl::not_null<t></t>？不行，gsl依赖<memory></memory>和异常机制；应改用断言宏assert(ptr != nullptr)+ 静态分析工具（如PC-lint）检查 -
R.11（用std::unique_ptr管理资源）→ MCU无operator delete实现；改用栈分配+RAII封装（如PinGuard类在析构中写GPIO寄存器） -
Pro.44（函数参数用std::string_view）→string_view构造函数含strlen调用，在无libc支持平台会链接失败；改用const char*+ 显式长度参数size_t len -
Enum.3（枚举必须指定底层类型）→ 看似安全，但enum class E : uint8_t在某些ARM GCC版本（如9.3.1）生成冗余位操作指令；建议仅对通信协议字段强制指定，内部状态枚举保持默认
可安全启用的关键子集（经FreeRTOS+ARM GCC 10.3验证）
以下Guidelines条款在裁剪后能显著提升稳定性，且无运行时开销：
立即学习“C++免费学习笔记（深入）”；
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
-
ES.101（使用auto推导类型）→ 仅限局部变量，避免模板实例膨胀；禁用auto&推导返回值引用（可能绑定临时对象） -
ES.28（用constexpr替代宏常量）→ 安全，但注意constexpr if（C++17）在GCC 10.3中需开启-std=gnu++17，且不得出现在头文件顶层作用域（避免ODR违规） -
F.16（函数参数优先用值传递小类型）→int、uint32_t、std::array<uint8_t></uint8_t>适用；但std::array<uint8_t></uint8_t>必须改用const std::array&，否则栈溢出风险高 -
ES.50（用[[nodiscard]]标记关键返回值）→ 编译期有效，不增加代码体积；特别适合HAL_StatusTypeDef HAL_UART_Transmit()封装层
实际裁剪配置示例（CMake + clang-tidy）
在CMakeLists.txt中设置基础约束：
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions -fno-rtti -fno-unwind-tables")
target_compile_definitions(${TARGET} PRIVATE
__STDC_FORMAT_MACROS
NO_MALLOC
GSL_THROW_ON_CONTRACT_VIOLATION=0)
配套.clang-tidy配置（仅启用可落地规则）：
Checks: >-
-cppcoreguidelines-*,
-cppcoreguidelines-avoid-magic-numbers,
-cppcoreguidelines-pro-bounds-array-to-pointer-decay,
-cppcoreguidelines-owning-memory,
-cppcoreguidelines-prefer-member-initializer,
-cppcoreguidelines-pro-type-reinterpret-cast,
-cppcoreguidelines-pro-bounds-pointer-arithmetic,
-cppcoreguidelines-pro-type-union-access,
-cppcoreguidelines-pro-type-vararg,
-cppcoreguidelines-pro-bounds-constant-array-index,
-cppcoreguidelines-init-variables,
-cppcoreguidelines-avoid-c-arrays,
-cppcoreguidelines-avoid-goto,
-cppcoreguidelines-avoid-non-const-global-variables,
-cppcoreguidelines-avoid-const-or-ref-data-members,
-cppcoreguidelines-avoid-mutable,
-cppcoreguidelines-avoid-reference-coroutine-parameters,
-cppcoreguidelines-avoid-c-arrays,
-cppcoreguidelines-pro-bounds-array-to-pointer-decay,
-cppcoreguidelines-pro-bounds-constant-array-index,
-cppcoreguidelines-pro-bounds-pointer-arithmetic,
-cppcoreguidelines-pro-type-reinterpret-cast,
-cppcoreguidelines-pro-type-union-access,
-cppcoreguidelines-pro-type-vararg,
-cppcoreguidelines-pro-bounds-array-to-pointer-decay,
-cppcoreguidelines-pro-bounds-constant-array-index,
-cppcoreguidelines-pro-bounds-pointer-arithmetic,
-cppcoreguidelines-pro-type-reinterpret-cast,
-cppcoreguidelines-pro-type-union-access,
-cppcoreguidelines-pro-type-vararg
真正起效的是前几行黑名单——把所有涉及动态内存、类型擦除、运行时检查的规则全屏蔽，再保留init-variables、avoid-goto这类零成本检查。
最易被忽略的一点：Guidelines文档里没写，但ARM Cortex-M硬故障（HardFault）绝大多数源于未对齐访问，而auto推导或std::array嵌套可能破坏结构体对齐。务必用alignof校验关键数据结构，并在启动代码中启用SCB->CCR |= SCB_CCR_UNALIGN_TRP_Msk捕获未对齐异常。
