FreeRTOS静态任务：TCB、栈与复用内存的生命周期
静态分配仍然需要管理寿命
xTaskCreateStatic()创建成功，不代表任务的存储以后可以随意清零或复用。内核虽然没有为它申请堆内存，却会继续使用任务控制块和栈。如果初始化函数返回后，其局部数组失效，或者重启逻辑提前覆盖旧任务的控制块，系统仍会损坏。本文以原生FreeRTOS Kernel V11.1.0为基线，删除顺序的具体推导采用单核前提；多核与厂商删除钩子需要单独审查。
固定版本任务接口要求提供StaticTask_t对象及StackType_t数组，栈深度按栈元素数量计算，不能直接把字节数代入。建议建立一张寿命表，记录存储地址、声明或分配者、当前任务代次，以及允许复用的条件。链接器分配的对象容易找到，但不能仅凭地址固定就认为内核不再引用它。
栈、控制块与参数都必须长期有效
对产品整个运行期都存在的任务，文件作用域或静态存储期对象比较容易审查。初始化函数里的自动数组，在函数退出后不能继续充当任务栈。创建时传入的参数指针也存在相同问题：内核保存的是指针值，不会自动延长该指针背后配置结构的寿命。
由应用内存池提供存储也可以，但必须满足所选端口的大小、对齐和有效期要求。池管理器应明确记录哪些槽位仍被任务使用，不能看到业务结束就归还。不要把栈放进可能被其他模块压缩、清零或重用的载荷区域。启用configSUPPORT_STATIC_ALLOCATION也不会消除其他库的动态分配，应分别盘点，不能据此宣称整个固件完全无堆。
业务完成不等于内核清理完成
任务报告“工作完成”属于应用协议；任务调用vTaskDelete(NULL)属于内核生命周期。这两个动作都不能单独证明所有控制块引用已经消失。V11.1.0会把仍在运行或准备让出的被删任务加入终止列表，随后由空闲任务处理。即使栈和控制块由应用提供、不需要释放回堆，终止列表及清理逻辑仍然存在，依据见该版本删除实现。
因此，任务在自删除前发送的完成通知，不能作为覆盖静态控制块的许可。管理任务可能先醒来，在旧清理路径执行前把同一地址初始化为新任务。等待一个时钟节拍也不是证明：优先级、调度器暂停及其他负载都可能使空闲任务没有机会完成清理。把偶然可行的延迟当作生命周期契约，会把故障留到更复杂的负载中。
优先复用工作任务本身
需要反复执行作业时，可以只创建一次工作任务，让它在两次作业之间阻塞等待命令。通过明确定义的复位命令重置业务状态，而不是清零任务栈。这种设计避免把产品重启逻辑绑定到内核内部删除时机，也方便按顺序关闭文件、停止DMA、释放互斥锁和归还载荷。
如果确实必须删除，应由管理任务实施协作协议：停止接收新工作，释放已持资源，确认到达安全边界，再进入约定的等待状态。对已经审查过的单核端口，管理者可以删除这个不在运行的任务，并依据该版本的同步清理分支决定何时回收。不能把这个结论照搬到另一核正在运行的任务。如果没有建立可靠的清理完成边界，就保留存储，不要猜测它已经空闲。
句柄与外部回调一起失效
TaskHandle_t代表一个实例，不是永久有效的服务名称。删除后应使用与访问者一致的同步机制，清除或替换所有公开句柄。延迟回调保存的旧句柄是独立风险，即使控制块已经被正确回收，也可能误操作后来创建的任务。地址恰好相同，会使这种代次混淆更难定位。
对于可能跨越重启的异步请求，可以增加应用代次号。回调在发出工作前检查所属代次，关闭时先停止它的生产源，再退役实例。代次号只是同步协议的补充，不能让已经释放的内存重新变得可访问。DMA描述符、网络连接和库状态也需要各自的关闭路径，删除任务不会自动执行C语言资源清理代码。
有意压测最危险的时间窗口
先核对链接映射和所有创建点：栈元素数、对齐、参数寿命，以及两个实例是否可能拿到相同存储。开发版本可以维护槽位登记表，让重复占用立即触发断言，而不是等到别的任务被破坏。这是建议的应用诊断，不是FreeRTOS自带的安全保证。
随后在受控环境中反复启动、停止和重启，并故意延迟空闲任务。覆盖正在等待资源、已经排入回调、刚报告业务完成等时刻。日志记录任务代次、句柄、槽位、安全点确认和回收决定。真正的验收条件是旧实例的内核可见寿命与新实例初始化没有重叠；仅仅循环很多次未崩溃，证据强度远低于直接验证顺序。
交付检查与边界
- 控制块、栈和创建参数均有明确所有者及有效期。
- 业务完成、任务删除和存储复用是三个不同状态。
- 自删除路径不凭通知或固定延时立即复用控制块。
- 句柄、回调和应用资源都加入关闭流程。
- 回收前审查实际端口的删除、多核和运行库清理路径。
- 报告注明准确构建版本和观察到的顺序，不扩展为通用重启保证。
本文只给出生命周期设计与源码核对方法，没有编译目标固件，也没有执行板级反复重启测试。
