Freertos任务调度这块内容，我前前后后翻过源码、画过状态图、也亲手把几个跑飞的项目拉回过正轨。说实话，任务调度是整个RTOS的“心脏”，搞懂它，后面的信号量、队列、互斥锁基本就是水到渠成的事。
现在不少初学 FreeRTOS 的朋友习惯直接调 API，任务能跑起来就行，一旦遇到任务不切换、低优先级饿死、系统卡死这类问题就彻底懵了。我写这篇东西，就是想带着你从头到尾把任务调度的全流程捋一遍：任务是创建了之后怎么排队，高优先级任务如何抢占 CPU，上下文切换底层到底做了哪些事，以及调试时遇到问题该怎么定位。这条链路打通了，你再看 FreeRTOS 的其他组件就会格外轻松。
这篇文章偏实战也偏原理，适合三类人：刚从裸机迁到 FreeRTOS、想让任务跑得更稳的开发者；已经在用但遇到调度异常、优先级不生效等问题的开发者；还有想深入理解内核机制、准备正经啃源码的人。前两节会有必要的原理铺垫，但我尽量用实际代码和场景串起来，保证不干巴巴。
1. 任务调度的核心设计思路
1.1 为什么任务调度是 RTOS 的心脏
裸机开发时，我们通常在主循环里轮询各个功能模块：读传感器、处理数据、刷新显示、响应按键。这种模型本身没有错，但致命缺点是阻塞。只要某个模块里出现了一个 delay 或者等待某个外设标志位，整个循环都得卡住，其他模块只能干等。这就是裸机实时性差的根源。
FreeRTOS 的解决思路是逆过来的：把代码切成多个独立任务，每个任务有自己的栈空间和执行上下文，调度器根据优先级和事件状态来决定“此刻 CPU 归谁”。一个任务在等待事件时，调度器不会傻等它，而是立刻切到另一个可以继续执行的任务。CPU 的空闲时间被榨干，系统的实时响应能力因此大幅提升。
理解这件事，一定要跳出“任务就是函数”的思维定式。任务是一个有状态、可挂起、可恢复的执行单元。它表面上就是个死循环加几个 API 调用，但背后有一个任务控制块（TCB）在随时记录它的一切。TCB 里存着栈顶指针、任务优先级、任务状态、事件等待列表等关键信息，调度器做的一切决策都围绕 TCB 展开。
从实际工程的角度看，用 RTOS 不是为了让代码显得“高档”，而是为了解决并行逻辑和多优先级响应的硬需求。比如一个采集系统里，数据采集必须严格 1ms 周期执行，但按键响应可以慢很多，界面刷新更不能拖累核心采集。在裸机上写这种混合速率的逻辑，代码很容易变成一团嵌套的标志位和中断。用任务调度来拆分，每个实时需求对应一个独立任务，调度器按优先级和时序分配 CPU，工程上清爽太多。
1.2 调度策略：优先级抢占与时间片轮转
FreeRTOS 的调度算法核心是两个词：优先级抢占式调度和时间片轮转。前者保证高优先级任务“想跑就能跑”，后者保证同优先级任务“轮流上桌”。
优先级抢占式调度的关键行为是：当一个更高优先级的任务进入就绪态时，当前任务立即被剥夺 CPU，不管它执行到哪一行。这一点和桌面操作系统的调度策略不同，RTOS 追求的是硬实时，宁可牺牲低优先级任务的流畅性，也要保证关键任务的截止时间不被错过。
时间片轮转则是针对同优先级任务的。系统每个时基中断（Tick Interrupt）触发一次调度决策，如果当前任务是同优先级队列里的第一个，而它的时间片已经用完，调度器就会把它挪到队尾，换下一个同优先级任务执行。FreeRTOS 默认的时基一般是 1ms，也就是说同优先级任务之间以毫秒级粒度轮流使用 CPU。
实际项目中，绝大多数场景用优先级抢占已经足够。比如一个串口透传项目，接收中断负责把数据放进环形缓冲区，一个高优先级任务处理并转发数据，另一个低优先级任务负责 OLED 显示。此时只要把处理任务设为高优先级，显示任务设为低优先级，整个系统的实时性就基本可控了，时间片轮转甚至可以完全不用。
但要注意一个坑：如果多个同优先级任务里有一个长期占用 CPU 且不主动让出，时间片轮转只能保证调度器给它“限时”，如果这个任务本身在时间片内死循环，其他同优先级任务还是会卡住。所以任务里面尽量不要做长时间阻塞的忙等，需要等待的事件一律用阻塞 API 而不是 while 轮询。
优先级数值这里需要单独说明。FreeRTOS 的优先级数值越大，优先级越高，默认最大优先级是 configMAX_PRIORITIES-1。很多从裸机转过来的开发者习惯“数值越大越不重要”，刚到 FreeRTOS 时常常写反，优先级配置错会导致整个系统的调度表现和预期完全不同。建议在工程里用宏定义封装任务优先级，不要散落裸数字。
2. 任务状态机与调度机制拆解
2.1 任务状态迁移全解析
FreeRTOS 的任务状态文档里写得清清楚楚，但很多人只记住了“运行态”和“就绪态”，忽略了另外两个关键状态：阻塞态和挂起态。四种状态可以总结成一张流转图：
- 运行态（Running）：当前占用 CPU 的任务。
- 就绪态（Ready）：具备运行条件、正在排队等 CPU 的任务。
- 阻塞态（Blocked）：在等待某事件或延时的任务，不在就绪队列里。
- 挂起态（Suspended）：被 vTaskSuspend 主动挂起的任务，只有调用 vTaskResume 才能恢复。
任务被创建后默认进入就绪态。调度器启动后，选择就绪任务中优先级最高的执行，此时它变成运行态。如果这个任务调用 vTaskDelay 或者等待队列、信号量，它就进入阻塞态，CPU 被让给下一个最高优先级就绪任务。阻塞态任务在事件满足后重新回到就绪态，等待调度器再次分配 CPU。
运行态的任务调用 vTaskSuspend 会进入挂起态。挂起和阻塞最大的不同是：阻塞有“超时时间”概念，事件没等到还可以靠超时自动醒来；挂起没有，它只能由外部显式调用 vTaskResume 来恢复。有些新手把挂起当延长版阻塞用，结果忘了在哪恢复，任务就永远“蒸发”了，系统行为变得非常诡异。
还有一个非常容易被忽略的状态细节：就绪态并不意味着马上运行。它只是说“这个任务有资格被调度”。实际能不能跑，还得看有没有更高优先级的任务挡在前面。所以一个低优先级任务明明在就绪队列里，却迟迟得不到 CPU 是很正常的，这是优先级抢占的正确行为，不是 bug。
从工程角度看，任务状态是调试系统行为的核心线索。嵌入式开发者手上的调试手段有限，很多时候就是“猜”。但如果你能随时说出当前每个任务在哪个状态、为什么在这个状态，系统问题的定位就成功了一大半。我习惯在代码里周期性打印所有任务的状态和栈高水位，这比出问题时再翻代码高效得多。
状态迁移的具体时机值得再展开一下。tick 中断是任务状态机的主要驱动力。每次 tick 到来，内核检查所有阻塞任务的超时条件，把超时到期的任务从延时列表中摘除，塞回就绪列表。同时内核还要检查当前运行任务的时间片是否耗尽，以及是否有比当前任务更高优先级的任务处于就绪态。这三个动作合在一起，就是调度器在 tick 中断里做的核心工作。
2.2 就绪列表与延时列表底层实现
FreeRTOS 源码里最频繁操作的数据结构是就绪列表，它本质上是一个由优先级索引的数组，每个元素是一个双向链表。优先级为 n 的任务挂在就绪列表的第 n 项上。调度器选择下一个要运行的任务，就是扫描这个数组，从最高优先级往下找第一个非空链表，然后取链表头部的任务。
这个设计非常聪明。扫描方向固定为最高优先级到最低优先级，每次调度的时间复杂度接近 O(1)，只在极端情况下才会多扫描几项。实际工程里优先级数量通常是十来个甚至几个，所以这个开销完全可以忽略。
延时列表则用来管理所有处于阻塞态的任务。任务在调用 vTaskDelay 或等待带超时的事件时，内核会把它插入延时列表，同时记录它的唤醒时间点。tick 中断到来时，内核从列表头部开始检查哪些任务到期了，把到期的任务移入就绪列表。为了提高这个过程的效率，FreeRTOS 还用了一个技巧：记录上一次 tick 到当前 tick 的时间差，批量处理到期的任务，而不是每次只处理一个。
理解这两个列表的数据结构，再看 FreeRTOS 的源码就不会觉得晦涩。pxReadyTasksLists 数组就是所有就绪任务的“家”，xDelayedTaskList1 和 xDelayedTaskList2 是延时列表的双缓冲。双缓冲的目的很直接：避免在 tick 中断里反复修改同一个列表导致链表操作复杂化。任务从延时列表摘除时，根据当前时间选择正确的延时列表来操作，这是源码里比较容易绕晕的地方，但本质上就是一个换表机制。
栈空间和 TCB 的关系也需要说清楚。任务创建时，内核从堆里分配一块栈内存，同时分配一个 TCB。TCB 里最重要的字段是 pxTopOfStack，它指向任务栈的当前栈顶。任务切换时，内核把当前任务的寄存器现场压入它的栈中，然后从新任务的栈中弹出寄存器现场。这就是上下文切换的数据基础。
动手验证这部分知识有个办法：在调试器里把当前 TCB 的内存打印出来，观察 pxTopOfStack 中的值是否指向合理栈区域，并且能看出一串寄存器备份。当发现 pxTopOfStack 指向的总是在某个固定地址附近跳动，说明栈使用正常；如果这个地址偏离太多，基本可以判定栈溢出或者任务栈分配过小。
3. 从创建到切换：任务调度全流程实操
3.1 任务创建与参数配置细节
任务创建是调度流程的起点。一个标准任务创建代码大致长这样：
TaskHandle_t xSensorTaskHandle = NULL; void vSensorTask(void *pvParameters) { for (;;) { /* 读取传感器、处理数据 */ vTaskDelay(pdMS_TO_TICKS(10)); } } void vAppInit(void) { BaseType_t xReturn = xTaskCreate( vSensorTask, /* 任务函数入口 */ "SensorTask", /* 任务名称，仅调试用 */ 256, /* 栈大小，单位是字，不是字节 */ NULL, /* 任务参数 */ 3, /* 优先级 */ &xSensorTaskHandle /* 任务句柄，可选 */ ); if (xReturn != pdPASS) { /* 创建失败处理 */ } vTaskStartScheduler(); }这里要注意几个极容易踩的坑。
第一，栈大小的单位是“字”。在 32 位处理器上，一个字是 4 字节，所以 256 实际上对应 1024 字节。很多从 8 位单片机转过来的人习惯性看成字节，结果栈配置偏小，任务跑到一半就栈溢出。建议在创建任务时统一用注释标注字节数，防止后续维护的人理解错。
第二，xTaskCreate 是从堆里分配 TCB 和栈内存的，堆大小由 configTOTAL_HEAP_SIZE 控制。如果这个值设小了，任务创建会返回 pdFAIL，但很多人不检查返回值，任务没创建成功就继续往下跑，系统一启动就表现异常，还找不到原因。创建任务之后必须检查返回值，这是底线。
第三，任务函数内部是不能正常返回的。一旦返回，系统会触发断言进入错误处理。有些新手在任务函数里放了 break 或 return，期望“退出任务”，这在 RTOS 里是不允许的。任务要么死循环执行，要么调用 vTaskDelete 自我删除。
栈大小预估是个实操问题。我一般先按经验估一个偏大的值，比如 512 字起步，然后跑一遍全功能测试，再通过任务栈高水位（uxTaskGetStackHighWaterMark）看实际峰值，根据峰值逐步调低到合理范围。不要一开始就想“精打细算”，栈溢出带来的调试成本远超多占用的几十字节 RAM。
任务创建时的优先级决定了它后续被调度的位置。实际项目中，优先级规划必须在创建前想清楚：中断上下文中唤醒的任务优先级要尽量高，周期性的核心处理任务要高，按键这类人机交互任务可以低，界面刷新类任务放最低。优先级满天飞的工程，后期调试会非常痛苦。
3.2 上下文切换到底发生了什么
上下文切换是任务调度最核心的动作，也是很多初学者最陌生的部分。简单说，它就是把当前任务的所有 CPU 寄存器保存进它的栈，然后从目标任务的栈里恢复所有寄存器，最后让 PC 跳转到目标任务继续执行的位置。这一过程在 FreeRTOS 里由汇编代码完成，因为它直接操作硬件寄存器，C 语言无法精确控制。
常见的触发路径有三种：tick 中断、任务主动让出（如调用 vTaskDelay 或等待事件）、外部中断里调用唤醒 API 导致的高优先级任务抢占。
以 tick 中断为例，完整的切换流程是：
- 硬件自动压栈一部分寄存器到当前任务栈。
- 进入 tick 中断服务函数，软件保存其余寄存器。
- 内核更新时基计数，检查延时列表和就绪列表。
- 如果发现有更高优先级任务需要运行，设置 PendSV 异常的挂起位。
- 退出 tick 中断后，PendSV 被触发，完成真正的寄存器切换。
这里有个关键点想强调：FreeRTOS 刻意把实际的上下文切换推迟到 PendSV 里做，而不是在 tick 中断里直接做。原因是 tick 中断可能打断其他中断，如果在 tick 里直接切换上下文，会拉长中断处理时间，而且可能破坏那些不允许被打断的中断现场。PendSV 是专门为上下文切换设计的异常，它的优先级可以被设为最低，这样所有普通中断都能抢在它之前完成，系统中断响应更及时。
任务主动让出时的切换路径类似，只是在任务代码里调用了一个软中断指令来触发 PendSV。这条路径不需要等待 tick，所以延迟更低。
上下文切换的性能直接影响系统实时性。每次切换大约在几十微秒级别，虽然这个时间看起来很短，但如果系统中任务切得非常频繁（比如每个任务都在 1ms 内多次让出），切换开销会显著吃掉 CPU。优化的方向不是降低切换本身的耗时（这是汇编级的事，普通应用改动不了），而是减少无效切换——合理设置时间片、避免高频度无意义让出、用事件通知替代轮询等待。
一个实际案例能帮助理解切换的重要性。某嵌入式项目里，两个任务互相高频率发送消息，任务 A 发完就等待消息，任务 B 收到消息处理完又回发消息，形成“乒乓效应”。这种场景下上下文切换极其频繁，如果切换开销是 30 微秒，两个任务来回 100 次就是 3ms 白白浪费。后来用队列批量处理加少量延迟，切换次数降了一个数量级，系统响应反而更流畅了。
3.3 优先级反转与互斥量使用
优先级反转是任务调度里最隐蔽也最让新手头疼的问题。它的典型场景是：任务 H 优先级最高，任务 M 优先级中等，任务 L 优先级最低。L 拿着一个互斥量，H 正在等待这个互斥量，此时如果 M 就绪了，M 会抢占 L 的 CPU，导致 L 无法释放互斥量，H 也跟着被卡住。这相当于中优先级任务 M 间接“压住”了高优先级任务 H，违背了优先级调度的基本语义。
FreeRTOS 的互斥量设计上加入了优先级继承机制：当高优先级任务 H 被一个低优先级任务 L 持有的互斥量阻塞时，L 的优先级会临时被提升到 H 的优先级，从而避免中优先级任务 M 插队抢占。等 L 释放互斥量后，它的优先级恢复原值。这套机制大大削弱了优先级反转的影响。
实际工程中，优先级继承并不能解决所有问题，它只能缩短反转窗口，不能完全消除。如果设计中有多处互斥量嵌套使用，反转风险会成倍增加。最稳妥的工程实践是尽量缩小临界区，用队列传递数据替代互斥量保护共享内存，从设计上避免长临界区和嵌套。
使用互斥量时的典型错误是忘了释放。互斥量不是信号量，它是有“所有权”概念的——只有获取它的那个任务才能释放。如果任务 A 获取了互斥量，又因为某个异常分支提前退出，跳过了释放代码，任务 B 将永远阻塞在这个互斥量上。这种 bug 的排查成本极高，因为看起来只是“某一个任务卡住了”。
我建议在写互斥量代码时遵循一个固定范式：获取后立刻在下一行记录状态标志，函数所有出口统一释放。如果代码复杂，可以考虑用“获取-操作-释放”三阶段封装成独立函数，避免在业务逻辑里散落获取和释放。
另外一个实际经验：能用队列解决的共享问题尽量不要用互斥量。队列的本质是数据的生产者-消费者模型，天然不需要锁，生产者写队列、消费者读队列，调度器保证同一时刻只有一个任务在操作队列内部结构。任务之间传数据，队列的代码可读性和可维护性远好于互斥量加共享缓冲区。
3.4 任务通知的高效等待与唤醒机制
任务通知（Task Notification）是 FreeRTOS 一个容易被人忽略但极其高效的特性。它本质上是直接修改目标任务 TCB 里的一个 32 位通知值，配合相关状态位，让目标任务快速进入或退出阻塞态。相比信号量和队列，任务通知不需要额外的内核对象，内存占用更小，速度更快。
任务 A 调用 xTaskNotifyGive 给任务 B 发通知，任务 B 在 xTaskNotifyWait 里等待。如果 B 事先调用了 xTaskNotifyWait 进入阻塞态，A 的通知会立刻把 B 唤醒，B 变为就绪态，并在下一次调度中立即执行。这个过程没有创建队列或信号量的开销，非常适合简单的“事件触发”型任务。
任务通知最常见的场景是配合外部中断使用。中断服务函数里不能调用阻塞 API，但可以调用 xTaskNotifyFromISR 来发通知。外部中断来了，ISR 先做必要的硬件处理，然后给对应任务发通知，任务被唤醒后在任务上下文里完成真正的数据解析和业务处理。这比在中断里做冗长处理要安全得多，也符合“中断处理要短”的原则。
市场上有不少老工程师习惯用信号量做中断唤醒，功能没错，但任务通知的开销明显更低。实测下来，任务通知的唤醒延迟比二进制信号量低三到五成，尤其在高频中断场景下，这个差距会被放大。如果你的项目里中断频率很高，强烈建议优先考虑任务通知。
任务通知的背景值用法也值得一提。它除了当简单的“闹钟”，还能累计通知次数。比如某种边沿检测中断，ISR 每触发一次就调用一次 xTaskNotifyFromISR，任务处理时用 ulTaskNotifyTake 消费这些通知。如果 ISR 触发频率高于任务处理速度，通知值会不断累加，这个计数器能直观反映“丢了多少次唤醒信号”。我在调试高频中断项目时，常把这个计数值打出来，一眼就能看出中断与任务处理之间的匹配度。
需要注意，任务通知只有一个通知值、一个状态位，所以它天然适合“一对一的简单事件通知”。多个任务同时等一个事件？用队列广播更合适。一个任务要等多个不同类型的事件？那就用事件组或者多路等待，任务通知就不够用了。选型时要看清楚场景。
4. 常见问题与排查技巧实录
4.1 任务不切换、卡死的排查思路
任务不切换是我见过最多的 FreeRTOS 问题，这类问题的表现几乎一样：系统跑起来后，某个任务永远不执行，或者所有任务全部卡死，只有看门狗能把它唤醒。排查思路应该按优先级从高到低排列，不要上来就翻源码。
第一步检查调度器是否真的启动了。vTaskStartScheduler 执行后，系统才会开始调度。如果初始化阶段就死循环或者发生了硬件错误，调度器根本没跑起来。最常见的原因是创建任务时调用了一个阻塞 API，而调度器尚未启动，导致卡死。
第二步检查各个任务的状态。在调试器里挂起系统，查看每个任务的当前状态。如果某任务一直处于 Ready 状态但永远不被调度，问题很可能出在任务优先级配置上——有更高优先级的任务长期占着 CPU，一直不释放。比如一个高优先级任务里的 for(;;) 循环没有放任何让出 CPU 的调用，它会霸占所有 CPU 时间，所有低优先级任务全部饿死。
第三步查 irq 是否被封禁。如果某段代码进临界区后没有正常退出，中断全部关闭，tick 中断也无法触发，调度器彻底瘫痪。这种 bug 最危险，因为系统表现为“完全无响应”，但其实就是某行代码少调了一个退出临界区的 API。
第四步看堆是否耗尽。如果动态创建任务失败，任务没有创建成功，但代码还在使用任务句柄操作它，结果就是操作一个空指针，大概率触发硬件错误，系统复位或者卡死。
排查卡死问题时，我强烈建议开启 FreeRTOS 的断言和钩子函数。configASSERT 定义后，内核会在参数错误和非法操作时立刻停下来，这比让系统“自由飞翔”再去猜测位置高效太多了。我见过太多项目，为了省一点编译体积把断言关掉，出了问题只能对着代码发呆。对于一个合格的工程，断言必须开。
4.2 栈溢出检测与定位
栈溢出是 FreeRTOS 工程的经典杀手。它不像逻辑错误那样有明确的表现，往往是系统运行几天后随机崩溃，或者某个任务突然行为怪异。栈溢出的本质是任务使用了超过分配范围的局部变量或者过深的函数调用链。
FreeRTOS 提供两种检测手段。第一种是利用任务栈末尾的校验值。每个任务栈末尾都有一段特殊填充值，系统可以定期检查这个值是否被改写，如果被改写说明栈溢出了。第二种是利用 MPU（如果硬件支持），在栈边界设置内存保护，任何越界访问都会触发硬件异常。日常调试用第一种就足够了，设置检查频率为所有任务切换时检查或者每 tick 检查，比较合适。
栈高水位 API 是排查栈溢出的第一助手。
configSTACK_DEPTH_TYPE usStackHighWaterMark = uxTaskGetStackHighWaterMark(xTaskHandle);这个 API 返回该任务从创建以来栈剩余的最小值，单位是字。如果这个值接近 0，说明栈几乎用尽，随时可能溢出。我的习惯是：每个任务的高水位必须保持 20% 以上余量，低过这个值就加大栈。
这里分享一个我曾经排查过的真实案例。某系统运行稳定，但每隔一段时间就有一台设备重启。经过长时间观察，发现重启前都有一个共同特征：一个特定任务在高负载时调用了一个很深层的字符串处理函数。由于这个任务栈初始配置偏小，深层函数调用导致栈顶压穿到相邻内存区域，改写了另一个任务的部分 TCB。系统若干时间后检测到 TCB 数据异常，触发断言复位。最终解决方案是给这个任务加大栈，同时优化了字符串处理的调用层级。这类问题的难点不在修复，而在复现——只有高负载时才触发，平时跑测试根本看不出来。
如果你在排查类似问题时无法复现，可以临时把所有任务的栈大小都调大一倍，看问题是否消失。这一步虽然粗暴，但能快速确认方向：如果系统恢复正常，基本锁定栈溢出；如果问题依旧，那就要去查别的原因了。定位后只改有问题的那个任务栈，不要全局增大浪费 RAM。
所有任务的栈高水位应当定期集中打印一次。不要在出问题时才开始测量，平时就要建立基线数据。哪个任务的栈用量最近明显变化了，那它附近大概率有代码改动或新逻辑引入。这种主动观测比事后排查省力得多。
4.3 调度器性能优化与设计建议
最后聊聊调度器性能的优化思路。很多开发者认为 FreeRTOS 的内核开销是固定的，其实不是。调度器的实际开销取决于任务数量、切换频率、临界区长度和中断频率。优化主要围绕降低这些开销。
第一，减少无意义切换。任务间高频互相通知是切换开销的主要来源。前面提到过乒乓效应，这类场景应该合并不必要的中间任务，或者调整任务优先级，让数据处理在同一个任务里完成，减少跨任务传递次数。
第二，合理规划 tick 频率。默认 1000Hz 的 tick 意味着每秒 1000 次定时中断。这个频率对大多数应用是合理的，但如果你的项目对时间精度要求不高，可以降到 100Hz，cpu 占用率立刻降低。当然，如果系统需要毫秒级定时，100Hz 就不够了，这是权衡问题。
第三，缩短临界区。临界区越长，系统对外部中断的响应延迟越大。把不需要保护的代码全部挪出临界区，只保护真正的共享变量操作。如果一个临界区里还夹着一些打印、延时、复杂运算，那这个设计就是有问题的。
第四，用事件驱动替代轮询。很多任务习惯用 vTaskDelay(1) 搭配轮询标志位来实现周期处理，这种方式确实简单，但会造成无效切换。更好的方式是用任务通知或队列让任务在事件真正到来时才被唤醒，没有事件时任务完全休眠，不占用任何 CPU。
从长远来看，设计任务时就要遵循几条原则：任务粒度不宜过细，一个任务负责一类完整的事情；任务优先级的层级不要太多，够用即可；不要在任务里做长延时，用事件驱动代替；所有共享资源明确归属，避免两个任务直接操作同一块内存。
我给一个实践参考。一个中等复杂度的嵌入式产品，通常 5 到 8 个任务就足够了：一个高优先级采集任务、一个中优先级处理任务、一个低优先级界面任务、一个通信相关任务、一个电源管理任务，再留几个辅助任务。任务超过 15 个就要怀疑划分是否合理了，任务越多调度开销越大，调试复杂度也直线上升。
调试时可以周期打印任务状态表，包括每个任务的名字、状态、优先级、栈高水位和运行次数。某任务运行次数增长异常，说明它被频繁唤醒，可以检查对应的事件源是否合理。运行次数长时间不变，说明该任务可能永远阻塞了。这种可视化监控对系统稳定性维护非常有价值。
从我个人的实际体会来看，玩转任务调度，最重要的一点是“先摸清状态机，再动手写代码”。网上很多教程都在教你 API 怎么调，却很少讲清楚任务状态之间的流转逻辑。但真正的问题往往出在状态流转上。你理解了任务为什么阻塞、为什么会进入就绪态、什么时候会被调度器选中，那么任何异常的调度行为都能迎刃而解。
另外一个小技巧是写代码之前先画出你的任务规划图：每个任务做什么、优先级多少、和谁通信、等在什么事件上。这张纸画完，后面的代码骨架基本就定下来了。我每次带着团队做项目，都会要求先画这张图，它比任何代码规范都更能避免后期的架构混乱。遇到调度问题时，重新对着这张图排查，通常能快速定位到设计层面的不合理之处。
