应主动监控堆使用量并在安全水位线阈值触发降级，而非等待分配失败；通过定期采样、滞后回差、可逆降级操作及状态解耦实现稳定资源管理。
内存耗尽前如何触发降级判断
嵌入式系统没有 malloc 失败回调，也不能依赖 std::bad_alloc（通常已禁用异常），所以必须主动监控——不是等分配失败，而是提前在阈值触发。关键动作是：定期采样当前堆使用量，并与预设安全水位线比对。
常见错误是只看 free() 返回值或 new 是否返回 nullptr，这已经晚了；更糟的是在 ISR 里调用 heap_caps_get_free_size()（ESP-IDF）或类似函数，可能引发重入或阻塞。
- 裸机/RTOS 下推荐用编译器内置函数获取堆状态，如
__heap_limit和__heap_start符号配合指针差值计算已用空间（需链接脚本导出） - 若用 FreeRTOS，优先走
xPortGetFreeHeapSize()，但必须在任务上下文调用，且建议每 100ms~1s 检查一次，避免高频扫描开销 - 安全水位线不能硬编码为“剩 512 字节”，而应按服务粒度预留：比如后台日志缓冲区最小需 256 字节，那水位线就得设在总堆剩余 ≤ 1KB 时触发
非核心服务如何安全降级而非直接 kill
“降级”不是停掉服务，而是收缩其资源占用并让出执行权。例如日志服务从“每条都缓存+加密+网络上传”降为“仅本地环形缓冲、禁用加密、关闭上传线程”。重点在于：所有降级动作必须可逆、无副作用、不破坏状态一致性。
容易踩的坑是用全局 flag 控制行为分支，结果在中断中读取 flag 导致竞态；或降级时释放了正在被其他模块引用的对象，引发悬垂指针。
立即学习“C++免费学习笔记（深入）”；
- 每个后台服务封装成独立类，提供
degrade()和restore()成员函数，内部只操作自身私有资源（如缩小缓冲区、暂停定时器、关闭 socket） - 降级过程禁止调用
delete或free，改用复位已有内存块（memset(buffer, 0, size)）和重置计数器 - 用原子变量（如
std::atomic<bool></bool>）标记当前状态，读写均加memory_order_relaxed即可，避免volatile的误导性语义
降级后如何防止反复震荡
内存水位在阈值附近小幅波动时，服务会在“降级 ⇄ 恢复”间反复横跳，造成逻辑撕裂和功耗毛刺。这不是理论问题——实测某采集设备在 RAM 剩余 980~1020 字节区间内，日志服务每 3 秒切换一次状态。
解决思路不是提高水位线，而是引入滞后（hysteresis）：恢复阈值必须显著高于降级阈值，形成回差。
- 设降级触发点为剩余 ≤ 1KB，则恢复点至少设为 ≥ 2.5KB（建议 2~3 倍）
- 降级动作本身要带延迟确认：触发后等待一个周期（如 200ms）再真正执行，期间若水位回升即取消
- 记录最近一次降级时间戳，10 秒内禁止二次降级，避免雪崩式连锁反应
为什么栈上对象不能替代降级逻辑
有人试图用“把日志缓冲区从堆移到栈上”来规避内存压力，这在技术上可行，但会掩盖真实问题：栈空间同样有限，且栈溢出比堆碎片更难诊断（往往直接覆盖返回地址）。更重要的是，栈对象生命周期与函数作用域强绑定，无法支撑后台服务所需的异步、跨任务、长周期运行语义。
真正的保活逻辑必须基于明确的资源所有权划分——谁申请、谁监控、谁降级。把缓冲区挪到栈上只是转移了风险点，没解决“服务如何响应系统资源衰减”这个本质命题。
最易被忽略的一点：降级策略必须与看门狗喂狗逻辑解耦。曾有个项目把降级检查放在看门狗喂狗路径里，结果内存紧张时喂狗超时，MCU 复位，刚降级的服务根本没机会生效。
