RAM监控必须用静态计数，预分配内存池+手动计数器，阈值设于75%并原子化降级，恢复需依赖外部信号与位掩码控制。
RAM使用率监控必须用静态计数，不能依赖运行时malloc统计
单片机没有操作系统提供的mallinfo或heap_caps_get_free_size这类接口（除非你用ESP-IDF等特化SDK），靠遍历堆链表查剩余空间既不可靠又破坏确定性。真正可行的是在编译期就锁定所有静态内存占用，并在运行时只跟踪“已分配的动态块数量”和“最大预设池容量”。比如你为网络模块预留了 256 字节的环形缓冲池，那就定义static uint8_t net_rx_buf[256]，再配一个uint8_t net_rx_used计数器——这个计数器每次收包+1、处理完-1，永远不越界，也不需要扫描内存。
常见错误是试图用free()返回值判断剩余空间，结果发现它在裸机环境下常返回固定值或直接报错；更糟的是有人在中断里调用类似函数，导致栈溢出或状态错乱。
- 所有全局/静态对象大小在链接阶段就确定，用
size命令或map文件可精确查出 - 堆内存必须用预分配池 + 手动计数，禁用
malloc/new - 栈空间单独监控：设置栈末尾为警戒值（如0xDEADBEEF），定期检查是否被覆盖
降级触发点要避开“临界抖动区”，建议设在RAM占用75%而非90%
等到RAM只剩10%才动作，往往已经晚了——某些任务临时变量、中断嵌套深度、函数调用栈帧可能突然吃掉几十字节，导致降级逻辑自己卡死。实测中，把触发阈值设在总可用RAM的75%，留出25%作为安全冗余，系统响应最稳。例如你有1KB RAM，其中256字节给栈、64字节给中断上下文、剩下700字节供业务使用，那么就在使用达525字节（75% × 700）时启动降级。
这个值不是拍脑袋定的：它要大于最大单次任务栈开销（查map里函数__stack_usage__节）、大于最深中断嵌套所需空间、还要容得下一次降级操作本身所需的临时变量（比如复制旧配置、关闭外设寄存器）。
- 不要用百分比硬编码，改用宏定义：
#define RAM_DEGRADE_THRESHOLD (RAM_TOTAL - RAM_STACK - RAM_ISR_MAX - 128) - 阈值检测必须放在主循环开头或调度器tick入口，避免被长任务阻塞
- 首次触发后应锁定降级状态至少100ms，防止抖动反复开关
非核心功能降级必须原子化关闭，不能只停任务调度
只调用scheduler.remove(task_id)或把任务函数指针置空，不等于资源释放。OLED驱动可能还占着SPI外设，蓝牙协议栈的TX缓冲区还在RAM里躺着，ADC采样中断仍会触发并往已失效的缓冲区写数据——这些才是真正导致崩溃的源头。
降级动作必须包含三件事：停调度、关外设、清缓冲。比如关闭日志上传功能，不能只停发送任务，还得：HAL_UART_DeInit(&huart2)、把log_tx_buf数组首字节写0、把相关DMA通道禁用。
- 每个可降级模块需提供
degrade()成员函数，封装上述三步 - 降级顺序很重要：先关输出类（LED、蜂鸣器），再停通信类（UART、BLE），最后才动采集类（ADC、I2C），避免上游数据无处可去
- 降级后保留一个最低功耗心跳灯（如每2秒闪1次），用于现场判断是否真“保活”成功
降级后的恢复机制比触发更难设计，别指望自动回弹
很多方案卡在“怎么恢复”上：RAM用下去了，但没地方记录“之前关了哪些模块”，或者恢复逻辑本身又吃掉200字节，导致刚升回来又触发第二次降级。真实项目里，恢复必须满足两个条件：一是有明确外部信号（如USB插拔、按键长按），二是只允许逐个模块手动恢复，而不是一键全开。
最轻量的做法是用一个uint8_t degrade_mask变量，每位代表一个模块（bit0=OLED、bit1=BLE、bit2=LOG_UPLOAD），降级时置位，恢复时通过外部事件清对应位。整个机制不依赖任何动态分配，只读写一个字节。
容易被忽略的一点：恢复某个模块前，必须确认其依赖资源已就绪。比如恢复BLE前，得先确认degrade_mask & (1为0（OLED已恢复），因为某些BLE状态提示要刷屏。这种耦合关系要在设计初期就画清楚，不能靠运行时探测。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
