企业官网建设流程全解析

1. 引言：嵌入式开发为什么需要重新审视 C++

在很长一段时间里，嵌入式系统几乎等同于 C 语言。原因很直接：C 语言足够贴近硬件，编译结果容易理解，运行时开销可控，工具链成熟，几乎所有 MCU、DSP 和 SoC 都优先提供 C 编译器。随着 Cortex-M、RISC-V、ESP32、STM32、i.MX RT 等平台的普及，以及汽车电子、工业控制、医疗设备、机器人、智能家居等场景复杂度上升，越来越多的团队开始尝试在现代嵌入式项目中引入 C++。

但“引入 C++”并不等于“照搬桌面端或服务端 C++ 的写法”。嵌入式系统对代码体积、RAM 占用、栈深度、中断延迟、实时响应和可审查性有严格约束。如果不加限制地使用模板、异常、STL 容器和虚函数，很容易得到体积膨胀、分配不可控、行为难以预测的二进制。因此，真正有意义的讨论不是“C++ 好不好”，而是“在嵌入式约束下，应该用哪一部分 C++”。

本文的核心观点是：现代 C++ 可以显著提升嵌入式代码的类型安全性、复用性和可测试性，但它必须被裁剪、分层和工程化。C++ 不是 C 的超集那么简单，它是一套可选择的语言机制集合。团队要做的，不是学会所有特性，而是明确哪些特性适合当前芯片和项目阶段，哪些特性需要折中，哪些特性应该直接禁止。

2. 先回答第一个问题：什么时候该用 C++

技术选型不能脱离产品形态、芯片资源、团队能力和维护周期。C++ 并非所有嵌入式项目的默认答案。判断是否使用 C++，可以从以下维度综合评估。

2.1 适合使用 C++ 的典型场景

• 应用逻辑复杂度高：项目包含协议栈、业务状态机、算法、配置管理、数据模型、单元测试等，需要更强的抽象能力。
• 硬件平台资源相对充足：Flash 达到 256 KB 以上、RAM 达到 32 KB 以上，或运行在 Cortex-M4/M7、RISC-V、Linux 嵌入式系统上，有空间容纳模板实例化和部分标准库设施。
• 长期维护和多人协作：产品生命周期长，代码需要反复迭代、测试和交接，类型安全和接口约束能显著降低维护成本。
• 需要复用跨平台模块：部分算法、模型、通信协议代码需要同时在嵌入式端、测试工具端或上位机端复用。
• 团队具备 C++ 经验：团队中至少有人理解对象生命周期、模板机制、编译期行为和 C++ 陷阱，否则引入 C++ 反而会增加风险。

2.2 不建议或应谨慎使用 C++ 的场景

• 极低资源 MCU：例如 Flash 小于 64 KB、RAM 小于 8 KB 的 8 位或低成本 16 位平台，C 语言通常更合适。
• 对认证要求极高且工具链受限：部分功能安全项目要求编译器、库和代码生成过程经过严格认证，C++ 运行时支持可能不满足现有认证包。
• 纯硬件驱动和寄存器操作：如果代码主要是寄存器读写、位操作和简单控制流程，C++ 抽象带来的收益有限。
• 团队缺乏 C++ 经验且项目周期短：学习成本可能导致更多隐蔽缺陷。
• 需要与大量遗留 C 代码深度交互：虽然 C++ 能调用 C 接口，但混合维护成本和边界设计成本可能超出预期。

2.3 快速决策清单

需要强调的是，嵌入式项目并不需要“全部用 C++”。很多团队采用 C 与 C++ 混合的方式：底层驱动、启动代码、中断向量表继续用 C，上层业务逻辑、协议处理、状态机和测试框架用现代 C++。这种混合策略往往比全量迁移更实际。

3. 嵌入式 C++ 的四个基本约束

讨论嵌入式 C++ 特性之前，必须先理解四个约束。任何特性是否可用，最终都要回到这四个问题上。

3.1 代码体积约束

Flash 是有限资源。模板每实例化一次，就可能生成一份新的机器码；虚函数会引入虚表；异常处理会插入栈展开表；标准库流会拉入大量格式化代码。一个没有约束的 C++ 工程可能比等价的 C 工程大数倍。因此，体积约束要求团队优先选择零开销或低开销抽象，并定期检查 map 文件。

3.2 RAM 与栈约束

嵌入式系统 RAM 通常很紧张，尤其是 RTOS 任务栈。递归、大对象按值传递、深拷贝、运行时多态都可能导致栈溢出或堆碎片。C++ 的对象生命周期管理如果使用不当，会产生比 C 更隐蔽的内存问题。

3.3 实时性与确定性

控制类系统要求在确定时间内完成响应。动态内存分配、异常抛出、锁竞争、隐式类型转换和复杂的模板推导，可能引入不可预测的时间开销。实时系统更关心最坏情况执行时间，而不是平均性能。

3.4 可调试性与可审查性

嵌入式代码经常需要在线调试、反汇编阅读和认证审查。过于复杂的模板、运算符重载、隐式转换和宏可能让代码难以定位问题。可维护性要求抽象不能遮蔽真实的资源消耗和调用路径。

4. 现代 C++ 特性的三层分类法

本文将 C++ 特性分为三类：推荐使用、折中处理和明确禁用。分类依据不是语言流行度，而是嵌入式场景下的资源开销、确定性、可调试性以及长期维护收益。

4.1 推荐使用：用低开销换取强类型与可维护性

这类特性在开启优化后通常不会带来显著运行时代价，却能减少低级错误、提高表达力。它们的共同特点是：错误能尽早暴露，代码意图清晰，且大多可在编译期完成。

4.2 折中处理：有用但有代价，需要规范和限制

这类特性在特定条件下能带来收益，但默认使用可能引入体积、时间或调试成本。应通过编码规范限定使用场景，而不是完全禁止。例如虚函数、模板、少量 STL 容器和原子操作。

4.3 明确禁用：默认禁止，除非有强理由并经过评审

这类特性在多数嵌入式场景下风险大于收益，应列入团队禁用清单。除非平台资源极其充足且团队能证明可控，否则不应在量产代码中出现。

5. 推荐使用的现代 C++ 特性

5.1 强类型与 enum class

传统 C 语言中的枚举会隐式转换为整数，不同枚举之间可以互相比较或赋值，容易产生逻辑错误。C++ 的enum class提供有作用域的强类型枚举，不能隐式转换为整数，必须显式转换。它还能指定底层类型，避免不同编译器下枚举尺寸不一致。

enum class UartParity : uint8_t { None, Even, Odd }; void config(UartParity parity) { // 不允许把 int 直接传进来 } UartParity p = UartParity::None; // 需要底层值时显式转换 uint8_t raw = static_cast<uint8_t>(p);

这类强类型检查几乎不增加运行时代码，但能显著减少配置参数错位、状态混用和跨模块接口错误。

5.2 constexpr 与编译期计算

constexpr允许在编译期计算常量表达式，常用于查找表、CRC 表、寄存器配置、协议常量和数据结构尺寸。与运行时初始化相比，编译期计算不会占用启动时间，也不会消耗额外的 RAM 来保存可变状态。

constexpr uint16_t crc16_table_entry(uint8_t index) { uint16_t crc = index; for (int i = 0; i < 8; ++i) { if (crc & 1) { crc = (crc >> 1) ^ 0xA001; } else { crc >>= 1; } } return crc; } constexpr auto crc_table = make_crc_table();

C++20 的consteval要求表达式必须在编译期求值，适合表达“必须静态确定”的配置和算法。需要注意的是，大量复杂的编译期计算会增加编译时间，但对运行时体积和性能通常是友好的。

5.3 RAII 与资源管理

RAII 是现代 C++ 最重要的资源管理思想，非常适合嵌入式中的锁、中断屏蔽、外设句柄、文件描述符和内存缓冲。对象在构造时获取资源，在析构时释放资源。这样即使函数提前返回或在错误路径上退出，资源也不会泄漏。

class CriticalSection { public: explicit CriticalSection() { __disable_irq(); } ~CriticalSection() { __enable_irq(); } CriticalSection(const CriticalSection&) = delete; CriticalSection& operator=(const CriticalSection&) = delete; }; void update_shared_state() { CriticalSection lock; // 无论下面如何返回，中断状态都会恢复 if (invalid()) return; do_update(); }

RAII 结合不可拷贝语义，能够把“进入临界区必须退出临界区”这类配对操作固化为类型约束，避免人工遗漏。

5.4 std::array、span 与固定容量容器

在嵌入式系统中，动态分配通常不受欢迎。C++ 提供std::array，它在栈上或静态存储区分配，大小在编译期确定，接口与标准容器类似，但不会调用堆分配器。

#include <array> #include <span> std::array<uint8_t, 256> buffer{}; void process(std::span<const uint8_t> data) { for (uint8_t byte : data) { handle(byte); } } process(buffer);

std::span在 C++20 中提供对连续内存的非拥有视图，可以统一数组、std::array和裸指针加长度的接口。它不分配内存，不拥有数据，非常适合驱动层与应用层之间传递缓冲区。

5.5 std::optional、std::variant 与错误返回

嵌入式代码经常遇到“可能没有值”或“可能是多种类型之一”的情况。std::optional可以表示空值语义，std::variant可以表示有限的类型集合。它们比使用裸指针、魔法值和联合体更安全。

#include <optional> #include <variant> std::optional<Frame> parse_frame(std::span<const uint8_t> bytes); using Command = std::variant<StartCommand, StopCommand, ResetCommand>; void dispatch(const Command& cmd) { std::visit([](const auto& c) { c.execute(); }, cmd); }

这类类型在开启优化后主要体现为结构体和标签值，通常不依赖堆分配。但要注意，如果嵌套过深或频繁按值传递大对象，也可能增加栈和拷贝开销，应结合具体结构体大小使用。

5.6 static_assert 与类型萃取

static_assert能把许多运行时检查提前到编译期，例如寄存器地址对齐、结构体大小、缓冲区尺寸、整数类型范围等。类型萃取可以约束模板参数，避免错误类型被静默接受。

static_assert(sizeof(FrameHeader) == 8, "FrameHeader must be 8 bytes"); static_assert(alignof(uint32_t) <= alignof(Buffer), "Buffer alignment is insufficient"); template <typename T> void to_little_endian(const T& value, std::span<uint8_t> out) { static_assert(std::is_trivially_copyable_v<T>, "T must be trivially copyable"); // ... }

这些设施不会增加运行时代码，却能在编译时阻止大量潜在问题，是嵌入式团队最应该优先采用的现代 C++ 特性。

5.7 删除函数与默认函数

= delete可以禁止对象的拷贝、移动或某些重载，= default可以明确保持编译器生成的默认实现。这两个语法有助于定义对象语义，避免意外拷贝导致缓冲区和外设句柄被复制。

class SpiDriver { public: SpiDriver() = default; SpiDriver(const SpiDriver&) = delete; SpiDriver& operator=(const SpiDriver&) = delete; ~SpiDriver() = default; };

这种约束对驱动类、单例资源和 RAII 句柄特别重要。

5.8 基于范围的 for 与 auto 的克制使用

基于范围的for可以简化数组和容器遍历。使用auto和const auto&可以避免重复类型，尤其在使用模板或标准库类型时。但嵌入式代码中应避免过度使用auto导致可读性下降，尤其在关键路径上更建议写出重要变量的类型。

for (const auto& entry : channels) { entry.process(); }

6. 需要折中处理的现代 C++ 特性

以下特性并非不能用，而是需要团队制定边界。它们的收益与成本都取决于使用方式。

6.1 异常机制

C++ 异常可以提供统一的错误传播路径，避免大量错误码逐层返回。但在 MCU 和实时 RTOS 环境中，异常处理会引入栈展开表、运行时类型信息以及不确定的执行路径。很多嵌入式编译器默认关闭异常，某些平台甚至不支持异常。

折中方案通常有两种：

• 全项目禁用异常：使用-fno-exceptions，错误处理回归返回码、std::optional、std::expected或自定义 Result 类型。
• 仅在应用层局部启用：底层驱动与中断上下文不使用异常，上层应用和测试代码允许捕获异常。这种混合方式需要非常清晰的边界和构建配置。

大多数量产 MCU 项目建议禁用异常，尤其是在无法评估栈使用和代码体积影响时。

6.2 RTTI

RTTI 用于typeid和dynamic_cast，会为多态类型增加元数据。如果项目不依赖运行时类型识别，应使用-fno-rtti禁用，以减少体积并提高可预测性。需要区分类型时，优先使用显式类型标签或std::variant。

6.3 虚函数与多态

虚函数是 C++ 实现运行时多态的核心，适合外设抽象、协议解析器、状态机接口等场景。代价包括虚表指针、间接调用和编译器的去虚化能力下降。在 RAM 极小且调用频率很高的平台，频繁虚函数调用可能影响性能。

嵌入式使用虚函数时建议：

• 接口保持纯虚且少量方法；
• 热路径避免通过虚函数执行微小操作；
• 可以结合final帮助编译器去虚化；
• 不要为了“设计模式完整性”引入过多层级。

6.4 模板与泛型编程

模板能提高复用性，并通过编译期多态避免虚函数开销。但模板会导致代码膨胀、编译时间增加和调试困难。深度模板元编程还可能让错误信息难以理解，使编译产物超出 Flash 预算。

折中做法是：模板参数保持简单，优先用于容器、算法和配置常量；避免递归深度过大的元编程；定期检查编译后的符号和段大小。对于明确的硬件类型，可以显式实例化模板以减少目标文件的重复生成。

6.5 STL 容器

std::vector、std::string、std::map等容器默认依赖动态分配，可能引入堆碎片、分配失败和不确定延迟。在嵌入式系统中，它们不是“不能使用”，而是必须知道分配来源和容量上限。

推荐使用std::array、std::span、std::optional、std::variant等不分配或静态分配的类型；如需动态容器，应使用固定分配器、std::pmr或手写环形缓冲。自由使用std::vector的嵌入式项目，通常需要引入分配策略和容量监控。

6.6 动态内存分配

多年运行的嵌入式设备最怕堆碎片和内存泄漏。new、delete以及默认标准库分配器不应在中断上下文或关键任务中无条件出现。折中方案包括：

• 启动阶段统一分配，运行阶段不再分配；
• 使用静态对象池或固定块分配器；
• 在特定模块内封装分配接口，便于替换；
• 禁用全局分配器或提供断言，在发布版本中监控最大水位。

6.7 线程、原子操作与并发

C++11 之后标准库提供线程、互斥量和原子操作。在 RTOS 或裸机环境中，标准线程库不一定可用或不符合任务模型。原子操作虽然能实现无锁队列和标志位，但硬件支持和内存序要求较高。

折中建议是：硬件相关和 RTOS 相关同步继续使用平台 API；标准原子类型可用于跨核心或中断共享的标志和计数，但必须选择合适的memory_order。不要为了“标准”而强行替换已经验证的 RTOS 同步原语。

6.8 标准 I/O 与字符串格式化

iostream、printf风格格式化会拉入大量代码和缓冲，且不是所有嵌入式工具链都完整支持。std::format在 C++20 中更安全，但也有体积与平台兼容成本。调试日志应尽量通过可裁剪的宏和 UART 驱动实现，避免依赖重型标准库。

7. 应禁用或严格限制的特性与写法

以下内容建议直接列入团队黑名单。即使某项在特定平台可用，也需要通过技术评审才能例外。

7.1 全默认异常与 RTTI

如果项目资源紧张，直接通过编译选项关闭异常和 RTTI，不需要在代码中使用。它们会让二进制体积、栈表、异常路径和调试复杂度明显上升。

7.2 不必要的动态容器和字符串

在驱动、协议解析、中断回调和控制循环中，避免使用std::vector、std::string等默认分配容器。堆分配不可预测，一旦分配失败或产生碎片，系统可能在下一次不可预测的时间点崩溃。

7.3 全局对象与跨编译单元初始化顺序依赖

C++ 全局对象的构造顺序在跨翻译单元时不确定，嵌入式系统中尤其容易因为外设尚未初始化就使用全局对象。应避免依赖全局构造函数，优先使用显式初始化函数、函数内静态变量或编译期初始化。

7.4 过深模板元编程与隐式转换

大量 SFINAE、递归模板和类型计算会让编译时间失控，也会使代码难以调试。隐式转换可能让错误参数“恰好”被接受，导致难以发现的运行时问题。应使用explicit限定构造函数和转换运算符。

7.5 运算符重载的滥用

运算符重载可以提升可读性，但在嵌入式代码中容易掩盖成本。例如重载operator+创建临时对象、重载operator[]产生隐藏的拷贝或计算，都会让性能分析误判。除数学类型和少数容器接口外，不建议重载运算符。

7.6 未定义行为模式

越界访问、有符号溢出、悬空指针、违反严格别名规则、未初始化变量读取、数据竞争等都属于未定义行为。现代编译器会基于“无未定义行为”的假设进行优化，某些 UB 不会按程序员想象的方式出错，而是产生更隐蔽的问题。应通过编译器警告、-fsanitize、静态分析和编码规范来避免。

7.7 在中断上下文使用重功能或锁

C++ 并不能自动解决中断安全问题。应明确禁止在中断服务程序中调用虚接口、动态分配、日志输出、互斥量锁定等可能阻塞或重入的操作。RAII 锁在中断上下文同样要谨慎使用。

7.8 无约束的 lambda 捕获与 std::function

lambda 本身是零开销抽象，但std::function可能进行类型擦除和堆分配。捕获大对象、引用局部变量或生命周期不明确时，容易出现悬空引用。嵌入式场景中应优先使用无捕获 lambda、模板参数或自定义函数指针，而不是默认使用std::function。

8. 嵌入式 C++ 的工程化实践

8.1 编译器选项与链接控制

构建变体直接影响 C++ 特性是否安全。项目应尽早固定下列关键选项：

• -fno-exceptions：默认禁用异常。
• -fno-rtti：默认禁用运行时类型识别。
• -fno-threadsafe-statics：如果不需要线程安全的局部静态变量，可减少相关运行时支持。
• -ffreestanding：在无完整宿主机运行库的裸机环境中使用。
• -fno-unwind-tables：进一步减少栈展开表。
• -Os或-Oz：体积优先优化，必要时对关键代码单独使用-O2。

同时应定期检查 map 文件、段大小、构造函数列表和编译警告。可以把体积和 RAM 纳入 CI，防止特性失控。

8.2 编码规范要点

• 接口使用enum class、std::span和明确返回类型。
• 所有构造函数中可能导致隐式转换的接口使用explicit。
• 资源类默认禁止拷贝，必要时实现移动语义。
• 禁止裸new/delete散落业务代码。
• 模板仅用于小型通用工具，业务代码避免复杂元编程。
• 公共头文件保持最小依赖，避免引入标准库重组件。
• 错误传播使用统一 Result 类型或返回码，而不是异常。

8.3 测试策略

现代 C++ 的一个重要优势是可在主机上对纯逻辑模块进行单元测试。协议解析、状态机、校验算法、配置管理都可以通过编译期或主机测试提前验证。硬件相关代码通过接口隔离和 mock 对象测试。CI 中同时运行主机单元测试、目标平台编译、静态分析和体积检查。

8.4 静态分析与代码审查

启用编译器的-Wall、-Wextra、-Wconversion、-Wshadow等警告，并将重要警告视为错误。配合 cppcheck、clang-tidy 等工具检查未初始化变量、越界风险、冗余拷贝和可疑生命周期。代码审查重点不是 C++ 语法是否正确，而是内存是否可控、栈是否可能溢出、中断是否安全、对象生命周期是否清晰。

9. 案例一：用现代 C++ 编写串口数据帧解析器

下面是一个适合嵌入式的数据帧解析示例。它使用固定缓冲区、std::span、std::optional、enum class和编译期常量，不依赖动态分配与异常。

#include <array> #include <cstdint> #include <optional> #include <span> enum class ParseError : uint8_t { Ok, HeaderInvalid, LengthInvalid, CrcInvalid }; struct Frame { static constexpr uint8_t Header0 = 0xAA; static constexpr uint8_t Header1 = 0x55; static constexpr size_t MaxPayload = 64; uint8_t command{}; std::array<uint8_t, MaxPayload> payload{}; size_t payload_size{}; }; constexpr uint8_t calc_crc(std::span<const uint8_t> data) { uint8_t crc = 0; for (uint8_t byte : data) { crc ^= byte; for (int i = 0; i < 8; ++i) { crc = (crc & 0x80) ? static_cast<uint8_t>((crc << 1) ^ 0x07) : static_cast<uint8_t>(crc << 1); } } return crc; } std::optional<Frame> parse_frame(std::span<const uint8_t> bytes) { if (bytes.size() < 4 || bytes[0] != Frame::Header0 || bytes[1] != Frame::Header1) { return std::nullopt; } uint8_t length = bytes[2]; if (length > Frame::MaxPayload || bytes.size() < static_cast<size_t>(4 + length + 1)) { return std::nullopt; } auto payload = bytes.subspan(3, length); uint8_t crc_expected = bytes[3 + length]; uint8_t crc_actual = calc_crc(bytes.first(3 + length)); if (crc_expected != crc_actual) { return std::nullopt; } Frame frame; frame.command = bytes[3]; frame.payload_size = length > 0 ? length - 1 : 0; for (size_t i = 0; i < frame.payload_size; ++i) { frame.payload[i] = payload[i + 1]; } return frame; }

这个解析器避免了堆分配和异常，输入缓冲区由调用方提供，错误通过std::optional表示。即使不深入了解 C++ 编译实现，其资源行为也基本可控。

10. 案例二：状态机实现与接口隔离

状态机是嵌入式开发中最常见的抽象。下面示例使用enum class表示状态，使用虚接口隔离硬件，但不引入动态分配与异常。

enum class MotorState : uint8_t { Stopped, Starting, Running, Fault }; class MotorControl { public: virtual ~MotorControl() = default; virtual void set_output(uint16_t duty) = 0; virtual MotorState read_fault() = 0; }; class MotorFsm { public: explicit MotorFsm(MotorControl& motor) : motor_(motor) {} void tick() { switch (state_) { case MotorState::Stopped: if (start_request_) state_ = MotorState::Starting; break; case MotorState::Starting: motor_.set_output(100); state_ = MotorState::Running; break; case MotorState::Running: if (motor_.read_fault() != MotorState::Fault) { motor_.set_output(running_duty_); } else { motor_.set_output(0); state_ = MotorState::Fault; } break; case MotorState::Fault: if (clear_fault_request_) state_ = MotorState::Stopped; break; default: state_ = MotorState::Stopped; break; } } void start() { start_request_ = true; } void clear_fault() { clear_fault_request_ = true; } private: MotorControl& motor_; MotorState state_{MotorState::Stopped}; uint16_t running_duty_{60}; bool start_request_{false}; bool clear_fault_request_{false}; };

状态机自身不感知底层定时器、PWM 或 GPIO 细节，硬件依赖通过MotorControl接口注入。单元测试时可以用一个 fake 实现记录输出，从而不依赖真实硬件。这种方式契合现代 C++ 的可测试性优势，也避免了数据类与硬件逻辑深度耦合。

11. 常见问题辨析

11.1 现代 C++ 一定比 C 慢吗？

不一定。许多现代特性在开启优化后能做到零开销或接近 C 代码，例如enum class、constexpr、static_assert、std::array、RAII 等。真正导致性能下降的往往不是 C++ 本身，而是无约束的动态分配、异常、深层虚函数和过度模板实例化。只要裁剪得当，C++ 可以达到与 C 相当的性能。

11.2 嵌入式项目是否应该从一开始就使用 C++？

如果芯片资源充足、团队有现代 C++ 经验且项目长期演进，可以从驱动层以上开始使用受限 C++。底层启动代码、向量表和部分库仍可使用 C。对于资源极低的芯片或认证工具链受限项目，保留 C 更稳妥。选择语言的关键不是先进性，而是全生命周期的总成本。

11.3 C++ 标准应该选哪个版本？

建议根据工具链支持选择 C++17 或 C++20。C++17 提供std::optional、std::variant、结构化绑定、if constexpr等实用特性；C++20 增加std::span、concepts、consteval和std::format。不要为了追求最新而使用尚未成熟或体积代价不明的特性。团队应建立“允许使用的标准库清单”。

11.4 可以用 std::vector 吗？

在没有堆分配禁止场景的模块中可以使用，但必须提供固定分配器或容量限制。如果系统没有堆、要求确定性或需要长时间运行，应避免std::vector默认分配。更好的做法是设计固定容量容器，并让核心路径完全不依赖动态内存。

11.5 异常和错误码如何选择？

量产嵌入式项目普遍建议禁用异常，使用统一错误码或 Result 类型。异常带来的栈展开表、运行时支持和不直观控制流在资源受限环境中通常不值得。如果上层应用确实需要异常，也应限制在应用层，不放到底层和中断路径。

12. 建立团队级 C++ 使用清单

技术团队不应只依赖个人经验，而应把 C++ 使用规则固化为文档和配置。清单至少包含以下内容：

• 允许使用的 C++ 标准版本与编译器版本。
• 已启用和已关闭的编译选项。
• 可用和禁用的语言特性列表。
• 标准库白名单与黑名单。
• 堆分配、异常、RTTI、模板、虚函数的使用边界。
• 驱动、中断、任务上下文中的不同限制。
• 体积、RAM、栈深度的预算与 CI 检查方式。
• 代码审查重点与静态分析规则。

清单不是限制创新，而是降低不可控风险。新人加入时可以快速理解“在这个项目里如何写 C++”，评审时也有明确依据。

13. 总结

嵌入式现代 C++ 的核心不是“使用多少特性”，而是“用可控的方式选择合适的特性”。一方面，enum class、constexpr、RAII、std::array、std::span、std::optional、std::variant、static_assert等特性可以提升类型安全、资源管理和代码复用能力，且通常不引入堆分配和异常机制的额外负担。另一方面，异常、RTTI、默认动态容器、全局对象初始化、过深模板元编程等特性在多数嵌入式场景下应当禁用或严格限制。

是否使用 C++，应结合 Flash、RAM、实时性、认证要求、团队能力和生命周期综合判断。更重要的是，无论选择 C 还是 C++，都需要用工程化手段控制资源：固定分配器、静态容器、显示编译选项、单元测试、静态分析和体积监控。只有这样，现代 C++ 才能真正服务于嵌入式产品，而不是成为难以维护的负担。

希望本文提供的分层清单、折中原则和两个案例，能帮助团队在下一个项目中更理性、更安全地使用现代 C++。