FreeRTOS下C++必须禁用new/delete和标准malloc/free，因实时性要求内存分配确定、无碎片、不可失败；应优先静态分配（栈或全局），动态场景用对象池替代堆分配。
FreeRTOS 下 C++ 面向对象编程的内存分配，不能依赖 new / delete，也不能直接用标准库 malloc/free —— 这不是语法问题，而是实时性、确定性和功能安全的硬约束。
为什么不能在 FreeRTOS 中随意 new 对象
嵌入式实时系统里，“不确定”就是 bug。标准 new 底层调用 malloc，而 malloc 的执行时间随堆碎片程度剧烈波动；更严重的是，它可能返回 nullptr，且无法在中断或高优先级任务中安全调用。FreeRTOS 官方明确不推荐 heap_3.c（即封装标准 malloc）用于关键路径。frt 等现代 C++ 封装库更是直接禁用动态分配，强制所有对象（Task、Mutex、Queue）静态声明。
常见错误现象包括：
- 任务创建失败但无明显报错，实际是
pvPortMalloc返回NULL导致xTaskCreate返回errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY - 系统运行数小时后突然卡死，大概率是堆碎片累积导致后续小内存分配失败
- ISR 中调用
new触发 HardFault —— 因为多数heap_x.c实现会挂起调度器，而 ISR 不允许挂起调度器
栈对象 vs 静态对象：何时用哪一种
在 app_main() 或任务函数内声明 Device device; 是最安全的做法：内存分配在栈上完成，构造函数立即执行，生命周期由作用域严格控制，零运行时开销。但要注意栈空间有限（ESP32 默认 4KB/任务），大对象（如含 1KB 缓冲区的 Queue）必须避免栈分配。
立即学习“C++免费学习笔记（深入）”；
静态对象（全局或 static 局部）放在 .bss/.data 段，生命周期贯穿整个运行期，适合跨任务共享的状态管理，比如：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
static Mutex my_mutex;—— 所有任务可安全调用my_mutex.take() -
static Queue<int> sensor_queue;</int>—— 缓冲区和控制结构全部静态分配，无需运行时申请 - 注意：静态对象的构造函数在
main()之前执行，此时 FreeRTOS 调度器尚未启动，不能调用任何带阻塞语义的 API（如take()、send()）
frt 库中类的内存布局必须显式声明
frt 的设计哲学是“静态分配优先”，所有资源占用在编译期可见。例如创建一个任务，你不能写 Task task([]{...});，而必须显式提供栈缓冲区和控制块：
static StackType_t task_stack[256]; // 1KB 栈空间
static StaticTask_t task_buffer;
TaskHandle_t handle = xTaskCreateStatic(
[](void* pvParams) { /* 任务函数 */ },
"my_task",
256, // 栈深度（单位：Word）
nullptr,
tskIDLE_PRIORITY,
task_stack,
&task_buffer
);这里 task_stack 和 task_buffer 都是静态数组，地址固定、大小确定。漏掉任一参数，链接会失败；栈太小则任务启动时触发栈溢出检测；栈太大则挤占其他全局变量空间 —— 这些都必须在编译期就权衡清楚。
heap_4.c 的隐形成本会影响 C++ 对象实例化密度
即使你选择 heap_4.c 并谨慎使用 new，每个分配仍产生至少 8 字节元数据（BlockLink_t）+ 对齐填充。例如申请一个仅含两个 int 成员的空类：class Sensor { int a, b; };，sizeof(Sensor) 是 8 字节，但 new Sensor 实际消耗约 16 字节（8 字节对象 + 8 字节头部）。频繁创建销毁小对象会快速耗尽本就不大的 heap（典型 ESP32 为 32–64KB），且加剧碎片。
真正需要动态生命周期的场景（如插拔式外设驱动），应改用对象池（object pool）模式：预先分配 N 个 Sensor 实例的数组，用位图或链表管理空闲索引，acquire()/release() 只操作索引，完全规避堆分配。
最关键的边界条件常被忽略：C++ 构造函数里若隐式调用了任何 FreeRTOS API（比如初始化一个内部 Queue），该 API 必须匹配当前分配方式 —— 静态 API（xQueueCreateStatic）还是动态 API（xQueueCreate）。混用会导致未定义行为，且调试极其困难。
