Zephyr 的 system workqueue：不用开线程也能干的延迟任务，中断底半部的标准答案

Zephyr 新手最常见的误区之一：稍复杂一点的逻辑就开一个新线程。线程多了，栈内存、上下文切换开销、优先级规划全是负担。其实很多「稍后执行一下」的活儿，根本不用开线程——Zephyr 的工作队列（workqueue）就是为这种场景设计的。

先讲原理。工作队列本质上是一个专用线程 + 一个 FIFO 任务队列。你把「工作项」（work item）提交进去，它按顺序逐个执行。系统默认就带了一个 system workqueue，免配置直接用。工作项有两种：普通 work（提交后尽快执行）和延迟 work（delayable，可指定毫秒数后执行、可取消）。

什么时候用工作队列、什么时候必须开线程？看两条线。第一，工作队列是串行的：同一队列里的工作项一个接一个跑，前一个阻塞，后面全堵住。所以 handler 里绝对不能做长时间阻塞等待（比如等信号量超时、sleep 很久）。第二，工作队列的执行上下文是线程上下文，可以调用 k_sleep、可以拿互斥量，这点比中断上下文宽松得多，但它不适合做周期性硬实时任务——抖动取决于队列里前面排了多少活。

实战中最经典的模式是「中断顶半部 + 工作队列底半部」。GPIO 中断、传感器数据就绪中断里只做一件事：k_work_submit() 把工作项丢给 system workqueue，中断立即返回。真正的 I2C 读取、数据解析、网络上报全在 work handler 里做。这样中断延迟极低，又不用为每个外设养一个常驻线程。

几个 API 记熟：k_work_init() 初始化工作项并绑定 handler；k_work_submit() 提交到指定队列（k_work_submit_to_queue）；k_work_schedule() 提交延迟 work，比如「按键消抖 50ms 后再确认」；k_work_cancel_delayable() 取消待执行的延迟项。注意延迟 work 的结构体是 k_work_delayable，不是 k_work，别混用。进阶用法：system workqueue 只有一个，某个 handler 偶尔耗时会拖慢别人的延迟 work，这时可用 K_WORK_QUEUE_DEFINE 自建带独立线程的队列做隔离。

最后提醒：work handler 里不要提交会无限自触发的 work（除非你明确要做周期任务并控制好退出条件）；真要周期执行，用延迟 work 的 k_work_reschedule() 更干净。

一句话：能用 workqueue 解决的延迟执行，别开线程；中断里只提交、不干活；重活儿自建队列隔离。这三条做到了，Zephyr 项目的线程数能砍掉一半，RAM 和调试复杂度都下来。

补充：system workqueue 是共享的，某个工作项阻塞或执行时间过长会拖慢其他工作项，所以耗时操作最好创建专用工作队列；另外 k_work_delayable 的重新调度（reschedule）语义要注意。你们项目里有遇到 system workqueue 被某个驱动阻塞导致其他功能延迟的情况吗？