C++在嵌入式系统中是理性选择，适用于资源较充裕的MCU（如Cortex-M4/M7）、长周期项目、RTOS环境等；需禁用异常、RTTI，避免new/delete和标准STL，采用静态内存、RAII、constexpr、模板等轻量级C++特性。

C++在嵌入式系统开发中确实被广泛使用，尤其在资源受限但又需要面向对象设计、类型安全和可维护性的场景下——比如物联网终端设备、工业控制器、车载模块等。它不是“越界”用法，而是有明确取舍的理性选择：放弃部分高级特性（如异常、RTTI、标准STL容器），换取确定性、低开销和对硬件的直接控制能力。

哪些嵌入式场景适合用C++？

不是所有MCU都适合C++，但以下情况值得考虑：

• 芯片资源较充裕（如ARM Cortex-M4/M7、RISC-V 64位核，带512KB+ Flash / 128KB+ RAM）
• 项目生命周期长、团队规模≥3人，需清晰分层（驱动层/协议栈/应用逻辑）
• 已有C++经验团队，或需与上位机（PC/云服务）共用算法模块（如PID、滤波、加解密）
• 使用RTOS（如FreeRTOS、Zephyr、ThreadX）并希望封装任务/队列/信号量为类接口

必须禁用或谨慎使用的C++特性

嵌入式C++ ≠ 桌面C++。关键原则是：避免不可预测的运行时行为和隐式内存分配。

• 禁用异常处理（-fno-exceptions）：抛异常会引入大量运行时支持代码，且堆栈展开不可控
• 禁用RTTI（-fno-rtti）：type_info和dynamic_cast增加ROM占用，且虚函数表查询有性能开销
• 避免new/delete（尤其在中断上下文或裸机环境）：改用静态内存池、对象池或栈分配；若必须动态分配，用定制allocator或RTOS提供的heap_xxx API
• 慎用std::string、std::vector等STL容器：它们依赖堆内存和异常；可用etl（Embedded Template Library）、folly::small_vector替代，或手写轻量级RingBuffer/StringView

推荐的嵌入式C++编码习惯

目标是让代码既保持C++的表达力，又具备C的可预测性。

• 用constexpr替代宏定义常量，用enum class替代#define状态码
• 用RAII管理资源：串口句柄、GPIO引脚、SPI总线等封装成类，在构造中初始化、析构中释放（确保无异常路径）
• 用模板替代宏函数：比如通用的CRC计算、字节序转换，类型安全且零开销
• 中断服务函数（ISR）里只做标记（如置flag、发消息），复杂逻辑交给主循环或RTOS任务处理
• 所有外设驱动接口统一抽象为接口类（纯虚函数），便于单元测试和硬件更换（如从STM32 HAL切换到Zephyr Driver）

工具链与生态支持

现代嵌入式C++已很成熟：

• 编译器：GCC ARM Embedded（arm-none-eabi-g++）、IAR EWARM、Arm Compiler 6 都完整支持C++17子集
• 构建系统：CMake + Ninja 是主流，配合toolchain文件精准控制编译选项
• 测试：CppUTest 或 Unity 可在主机或QEMU中跑单元测试；结合覆盖率工具（gcovr）评估关键路径
• 典型框架：Zephyr RTOS原生支持C++；Mbed OS提供C++友好API；AWS IoT Device SDK for C++也适配ARM Cortex-M

基本上就这些。C++在嵌入式里不是炫技，而是用得克制、理得清楚、测得扎实——尤其在物联网设备越来越“智能”、固件越来越“厚”的今天，它正成为平衡效率与工程性的务实之选。