FreeRTOS中C++全局构造函数不执行，因启动流程未调用__libc_init_array()；需在main()开头手动添加该调用，否则static对象、std::mutex等均失效。
FreeRTOS 中 C++ 构造函数不执行？因为 main() 之前没调用 __libc_init_array()
FreeRTOS 默认的启动流程跳过了标准 C++ 运行时初始化，全局对象的构造函数不会自动运行，这是最常被卡住的第一步。
- 裸机启动文件（如
startup_*.s）通常只调用main()，不调用__libc_init_array()—— 而它才是触发.init_array段中 C++ 构造器的关键 - 在
main()开头手动加一句：__libc_init_array();（需包含<stdlib.h>或直接声明），否则所有static类对象、constexpr初始化、std::mutex全局实例全失效 - Zephyr 没这个问题：它默认启用
CONFIG_NEWLIB_LIBC或CONFIG_CPLUSPLUS后会自动处理，但 FreeRTOS 移植层必须自己补
Zephyr 的 std::thread 不能用，替代方案是 k_thread + std::function
Zephyr 不提供 POSIX 线程兼容层，std::thread 在编译期就会报错 —— 它依赖 pthread_create，而 Zephyr 只有 k_thread_create()。
- 别写
std::thread t([]{ ... });，链接失败：undefined reference topthread_create - 改用 Zephyr 原生线程封装：先定义
std::function<void> task_fn</void>成员变量，再在k_thread启动函数里调用它 - 注意栈大小：C++ lambda 捕获对象会增大栈用量，
k_thread_stack_define分配的栈要留足余量（比如 +512 字节），否则硬故障无声挂掉
FreeRTOS + C++ 的虚函数调用变慢？检查 vtable 是否进了 RAM
ARM Cortex-M 上常见现象：开启 -fno-rtti -fno-exceptions 后虚函数调用仍慢，甚至 crash —— 很可能是 vtable 被链接到 Flash，而 CPU 访问 Flash 比 RAM 慢 2–3 倍，且某些芯片（如 STM32L4）对 Flash vtable 有额外限制。
- 确认 vtable 地址：在 map 文件里搜
.rodata.*vtable，看它落在FLASH还是RAM区 - 强制搬进 RAM：在 linker script 里加
*(.rodata.vtable)到 RAM 段；或用__attribute__((section(".ram_rodata")))标记关键基类 - 更稳妥的做法是避免虚函数：嵌入式场景下用策略模式 + 函数指针往往更可控、体积更小、行为可预测
std::vector 和 std::string 在 Zephyr/FreeRTOS 中不是“开箱即用”
它们底层依赖 malloc/free，而 Zephyr 默认用 slab allocator，FreeRTOS 用 pvPortMalloc —— 但 STL 容器并不知道该调哪个，直接用会链接失败或内存踩踏。
立即学习“C++免费学习笔记（深入）”；
- Zephyr 需显式开启：
CONFIG_STL（Zephyr 3.4+），并确保CONFIG_NEWLIB_LIBC或CONFIG_MUSL_LIBC已设，否则std::vector::push_back编译不过 - FreeRTOS 下建议绕过 STL：用
std::array+ 手动 size 计数，或封装xQueueCreate/FreeRTOS内存池做简易容器 - 哪怕编译通过，也要检查
configTOTAL_HEAP_SIZE是否够大——一个std::string默认可能分配 16~32 字节，频繁 resize 会碎片化
虚函数、全局构造、内存分配这三块，最容易在调试后期才暴露，而且错误表现五花八门：串口突然停发、定时器不准、某个对象成员值是随机数……其实全是同一类底层机制没对齐导致的。
