Zephyr RTOS内核基础：工作队列与延迟工作一次现场调试的教训去年在做一个工业网关项目，MCU是STM32H743，跑Zephyr 2.7。现场反馈设备运行几小时后，Modbus TCP响应越来越慢，最后完全卡死。远程抓日志发现一个诡异现象：中断服务函数里调用了k_sem_give，但等待该信号量的任务始终没被唤醒。排查三天，最终定位到问题——我在一个高优先级中断里直接调用了k_work_submit，而工作队列处理线程优先级低于中断触发的另一个任务，导致工作项被无限期推迟，连带信号量操作也出了问题。这个坑让我彻底理解了Zephyr工作队列的设计哲学：工作队列不是万能的中断下半部，它有自己的调度规则和优先级约束。工作队列的本质：一个被精心设计的线程池Zephyr的工作队列（Work Queue）本质上是一个专用线程，它维护一个待处理工作项链表，循环取出并执行。每个工作队列对应一个线程，线程优先级、栈大小在创建时固定。// 定义一个工作队列，栈大小2048，优先级5K_THREAD_STACK_DEFINE(my_workq_stack