RTOS任务详解：从状态机到调度器，一次搞懂嵌入式多任务核心

搞嵌入式开发的人第一次接触 RTOS，十个里有九个会卡在同一个问题上：任务到底是什么？我见过不少从裸机转过来的同事，翻了几篇文档、看了一堆 API，代码能跑起来，但心里始终是悬的——任务的栈是干嘛的？为什么任务要写成死循环？调度器凭什么把我这个任务踢走？这些疑问不解决，后面调起 Bug 来就是灾难。

RTOS（实时操作系统）里的任务，说穿了就是一段独立的可调度执行流，你可以把它理解成"一个有独立栈空间、独立运行状态的函数"，由内核统一管理它的运行节奏。整个 RTOS 的调度、通信、同步，全都建立在对任务的管理上。这篇文章我按自己在项目里的理解和踩坑经验，把任务从定义、状态、调度、通信到实操配置、常见问题完整拆一遍，适合刚入门 RTOS 的嵌入式开发者，也适合那些已经写过几个 RTOS Demo 但总觉得概念没打通的人。

1. 任务到底是个什么东西：先把"伪并行"的底牌揭开

1.1 从超级循环到多任务：一次思维换代

绝大多数单片机工程师的第一段代码都是这个套路：

void main(void) { while (1) { KeyScan(); /* 扫描按键 */ DisplayUpdate(); /* 刷新屏幕 */ DataProcess(); /* 处理数据 */ BuzzerCtrl(); /* 控制蜂鸣器 */ } }

超级循环不是不能用，很多简单产品到现在也是这么跑的。但它有两个让人头疼的先天问题：一是所有功能串在一个循环里，任何一个模块跑得慢了，后面所有模块都得跟着等；二是实时性完全没有保障，按键按下去可能要等好几轮循环才能被响应，你根本说不准这个"几轮"到底多久。

RTOS 做的事，不是把你原来的主循环删掉，而是把里面每一个处理块拆出来，让它成为一个独立的"任务"。你可能会想：单片机就一个核，怎么可能同时跑多个任务？

这里面最关键的一点是：单核 CPU 同一时刻确实只能执行一条指令，RTOS 也不会打破这个物理规律。所谓的"多任务并行"，其实是内核在让多个任务快速地轮流使用 CPU——每个任务跑一小段时间就切换出去，换下一个进来。因为切换速度很快，人眼和业务逻辑几乎感知不到，就造成了"大家同时在跑"的错觉。这就是所谓的时间片轮转；再加上优先级抢占机制，高优先级任务随时可以打断低优先级任务，把 CPU 抢过来先用。

所以任务这个概念真正的价值，不是物理层面的并行，而是逻辑层面的并行。你把原本纠缠在一起的一大坨业务逻辑，按功能边界切成几个独立单元，每个单元只关心自己的输入输出，剩下"谁先跑、跑多久、什么时候让位"这些破事全部交给内核。你会发现，写代码的思路完全变了——从"我该怎么安排执行顺序"变成"我该怎么划分任务边界"。

1.2 任务的骨架：函数体、栈、TCB，一个都不能少

从代码形态上看，一个任务就是一个函数，但并不普通，它有四个硬性特征：

void my_task(void *param) { while (1) { /* 干正事：等待数据、处理、输出 */ wait_event(...); process(); output(); task_delay(10); /* 主动让出 CPU，进入阻塞 */ } }

第一，任务是死循环结构。绝大多数任务的主体都是while(1)，因为它被创建之后，内核默认把它当作一个常驻的"活体"来管理，希望它永远处于可以被调度的状态。如果任务函数return退出，这个任务就等于终止了，想再让它干活只能重新创建。某些 RTOS 允许任务自己删除自己，但那是显式调用 API 的行为，不是自然返回。

第二，任务函数不能像普通函数那样结束。普通函数return之后，栈就回收了，控制权回到调用者；任务没人"调用"它，它一旦退出，内核手里就只剩一个空壳 TCB，调度时再把它选出来运行就没有任何可执行的代码了，这会直接引发系统错误。

第三，任务有自己独立的栈。这个栈用来存放局部变量、函数调用的参数和返回地址。每个任务的栈空间是在创建时由你分配的，栈大小给少了任务跑着跑着就溢出，给多了浪费 RAM。这是后面实操部分的重头戏，我单独展开。

第四，每个任务在创建时都会被分配一个核心数据结构，行业内一般叫 TCB（Task Control Block），翻译过来就是"任务控制块"。TCB 是这个任务在系统里的唯一档案，里面记录着任务函数的入口地址、栈顶指针、当前状态、优先级、以及任务名之类的元信息。调度器干活的时候不看你的代码，只看 TCB。你可以把 TCB 理解成图书馆里一本书的索引卡——书本身是任务函数和栈，索引卡则记录着这本书现在被谁借走、还剩多少页没读。

1.3 任务和普通函数调用：本质区别一张表看清

很多新人最大的困惑是："我不就在循环里调用一个函数吗？跟任务有什么本质区别？"区别非常大，我用表格对比一下：

对比项	普通函数调用	RTOS 任务
执行方式	被调用者主动调用，调用完返回	由内核调度器选出来运行
栈空间	使用调用者的栈（共用）	使用自己的独立栈
运行状态	调用完就结束，没有状态概念	有运行/就绪/阻塞等状态，由内核管理
主动让位	必须从头到尾跑完才能返回	可以随时主动阻塞，把 CPU 让给别人
恢复方式	返回地址自然恢复	靠上下文切换恢复现场
生命周期	随函数结束而结束	独立存在，可以反复运行直到被删除

普通函数是"你叫我跑我才跑，跑完就消失"；任务则是"我在系统里挂了号，调度器觉得该我上场就上场，不想跑了我可以先去睡觉，醒了继续接着跑"。

打个生活化的比方：普通函数像你叫了一个临时工，干完活就结账走人；任务像公司里的一个正式员工，有自己的工位（栈），有工牌（TCB），有职级（优先级），HR（调度器）负责安排他什么时候上班、什么时候下班，他工作途中还可以申请休息（阻塞等待消息/事件）。

理解了这一点，后面所有关于调度、状态、阻塞的内容就都好说了。

2. 任务的三种状态：运行、就绪、阻塞，读懂状态机就懂了一半

2.1 核心状态机：每种状态代表什么

任务不是一直在跑的，它在系统里只可能是下面三种核心状态之一：

• 运行态（Running）：当前正在占用 CPU 的任务。单核系统里同一时刻只有一个任务处于运行态。
• 就绪态（Ready）：任务已经具备运行条件，什么资源都不缺，就等 CPU 空闲下来。就绪的任务排在一个叫"就绪队列/就绪表"的结构里。
• 阻塞态（Blocked）：任务在等某个事件或资源，比如等信号量、等消息队列、等延时结束。阻塞态的任务不参与调度，CPU 轮不到它。

部分 RTOS 还有一个挂起态（Suspend），需要通过专门 API 进入或唤醒。但对于理解核心机制，先把上面三个状态焊死在脑子里就够了。挂起态无非是"被人为按了暂停键"，和阻塞态最大的区别是，阻塞态是被系统内的资源/事件条件触发的，而挂起态是被别的任务或中断主动调 API 控制的。

状态机的价值在哪？它决定了调度器"选谁、不选谁"。调度器不关心你这个任务在干什么，它只看就绪表——只有就绪态的任务才有资格被选中，阻塞态的任务直接不参与竞争。

2.2 一次完整的任务状态流转实例

光讲理论太干，我拿一个非常常见的通信场景走一遍流程。假设系统里有三个任务：

• 任务 A：按键扫描，优先级最高，平时等一个"按键按下"的信号量。
• 任务 B：屏幕刷新，优先级中等，平时在死循环里刷界面。
• 任务 C：数据存储，优先级最低，平时等存储事件。

系统启动后的典型时序是这样的：

1. A 创建后调用"等待信号量"接口，发现没有信号量，立即从运行态切到阻塞态。
2. 调度器扫一遍就绪表，发现 B 就绪，切换上下文，B 进入运行态，开始刷屏幕。
3. 用户按下按键，产生中断。中断服务程序里做最小限度处理（清标志位），然后通过一个"从中断发送信号量"的专用接口唤醒 A。
4. 退出中断后，内核发现 A 变成就绪态，而且优先级高于 B，直接抢占。B 从运行态回到就绪态，A 进入运行态，开始处理按键逻辑。
5. A 处理完，再次等待信号量，变阻塞，调度器又把 CPU 交给 B。
6. 中途如果有存储任务被触发，类似地按优先级顺序再走一轮。

整个过程里，作为开发者你只需要做两件事：在任务 A 里写"等信号量、处理按键"的代码，在中断里写"发信号量"的代码。至于谁被抢占、谁先跑，内核全部自动处理。这就是状态机加调度器为你省下的心智负担。

2.3 阻塞和延时的正确姿势：别再写空循环拖时间是新手必修课

从裸机转过来的工程师最常踩的坑，就是在任务里写这种代码：

/* 错误示范：用空循环模拟延时 */ for (volatile int i = 0; i < 100000; i++);

我之前说过任务被阻塞后不参与调度，但空循环完全不一样——它不会让出 CPU，任务始终处于运行态，把 CPU 给吃死了。别的进程都被晾在旁边，实时性直接崩盘。

RTOS 的正确做法是调用阻塞式延时 API，比如常用的task_delay。这个 API 做的事情是这样的：把当前任务从运行态摘下来，标记为阻塞态，设置一个定时信息，然后内核立刻去调度别的任务。延时时间到了之后，由内核定时机制把这个任务重新放回就绪表，等待调度。

作为工程师你必须清楚一个底层事实：你在裸机里写的空循环，本质上是"主动占着 CPU 不让别人干活"；而你调用task_delay，本质上是"告诉内核我这段时间不需要 CPU，你安排别人吧"。这两种行为在几乎所有的嵌入式业务里，对系统实时性的影响是数量级的差异。

同理，等待消息队列、等待信号量的时候，也一定要使用带阻塞参数的等待接口，而不是用while(queue_is_empty());去轮询。轮询在极端情况下似乎"响应更快"，但它同时让 CPU 完全无法被其他任务使用，属于拿系统整体实时性换单个任务响应速度，哪怕在工业产品里也是大忌。

3. 调度器与上下文切换：任务背后的"舞台导演"在忙什么

3.1 抢占式优先级调度：RTOS 的硬规矩

不同 RTOS 调度策略细节有差异，但主流 RTOS（无论是开源还是商业内核）默认采用的核心策略都是一样的：优先级抢占式调度。具体规则就两条：

• 高优先级任务一旦进入就绪态，立即抢占当前运行的低优先级任务。
• 相同优先级的多个任务，则按时间片轮流使用 CPU，或者按先来先服务的方式排队，取决于配置。

优先级抢占式调度最大的好处是确定性。你能明确算出"我的高优先级任务从事件发生到被调度执行，最长需要等多久"——这个时间主要由中断关闭时间决定。这也是实时操作系统敢叫"实时"的根本原因：关键响应的延迟有上界，而不是靠运气。

与之相对的是协作式调度，要求任务自己主动让出 CPU，只能通过阻塞 API 触发调度，别人不能打断它。协作式调度在任务跑大循环时没及时让位，就会把整个系统拖到崩溃，所以现代 RTOS 里应用较少，但理解它的存在能帮你反衬抢占式的优势。

3.2 上下文切换到底切了什么：寄存器、栈指针、程序计数器

"上下文切换"这个词一听就劝退，其实它本质就是一件事：换人干活之前，把当前这个人干活的现场完整记录下来；换下一个人上场时，把记录好的现场原样恢复出来，让他接着上次中断的地方继续。

现场包括哪些东西？具体来说：

• 通用寄存器组（R0-R15 这类）
• 程序计数器（PC，也就是当前执行到哪条指令）
• 处理器状态寄存器
• 当前任务的栈指针
• 如果系统用了浮点单元，浮点寄存器也得存

实际切换动作可以拆成这几步：

1. 触发调度点（任务主动阻塞、延时、中断退出等）。
2. 把当前 CPU 寄存器的值全部压入当前任务的栈。
3. 把栈顶地址保存到当前任务的 TCB 里。
4. 从下一个任务的 TCB 里取出它的栈顶地址，加载到 CPU 栈指针。
5. 从栈里弹出之前保存的寄存器值。
6. 从程序计数器指向的位置继续执行。

前面几步是"保存现场"，后面几步是"恢复现场"。汇编层面做这件事通常只需要几条到十几条指令，非常快，一般几微秒到几十微秒量级。

我习惯用一个例子跟新人解释：你正在写一份文档，写到第三页第二段，突然来了个电话。你先把文档翻到哪儿、写到哪个字记住，然后去接电话；接完电话回来，翻回那一页，接着往下写。这个"记住进度再恢复"的动作，就是上下文切换。

初学者可以暂时不必手写切换的汇编实现，但必须建立两个直觉：切换是有成本的；切换成本发生在每一次阻塞、每一次抢占里。如果系统里满屏都是"短任务的频繁切换"，那 CPU 大量时间就浪费在"来回换人"而不是"干活"上了。

3.3 切换成本的工程考量：不是越快越好

在工程上有一个很容易被忽略的平衡问题：任务划分得越细，切换越频繁，系统开销越大。比如你把一个温度采集逻辑拆成三个任务：读传感器、滤波计算、上报数据。每个任务都是几百微秒的活，中间还互相等队列——一次数据流要经历三四次上下文切换，假设每次切换 10 微秒，额外开销就相当可观了。

我的经验是把"正交性"和"开销"摆在一起权衡：任务边界应该切在"事件驱动频率不同"或者"实时性要求不同"的地方。如果两个逻辑总是同一频率、同一优先级、同一事件驱动，强行拆成两个任务只会增加切换开销和通信复杂度，不如合并成一个任务内部按状态机处理。

另一个工程细节是中断对上下文切换的影响。中断服务程序执行期间，某些实时内核允许中断打断任务，但不允许任务切换发生（取决于内核实现）。如果你在中断里放太多活，不仅中断延迟变长，还间接拉长了任务切换的等待时间。所以中断里切忌跑大段业务逻辑，原则永远是"中断里只做标记，活留给任务干"。

4. 任务的"情感交流"：通信与同步机制必须搞明白

4.1 为什么共享全局变量容易出事

任务之间总有配合干活的时候，比如任务 A 采集到数据，任务 B 拿去做显示。很多新人的第一反应就是定义一个全局变量，A 写、B 读，搞定。这个方案在小系统里偶尔能跑，但在 RTOS 里是定时炸弹。

问题出在哪？任务 A 和 B 的执行顺序不是你能控制的。A 在写一个多字节变量时，可能刚写了高字节，还没写低字节，调度器就切到 B 去读了——B 读到一个半新半旧的数据，这在行业内叫"数据撕裂"或竞态条件。比数据撕裂更隐蔽的问题是编译器和缓存带来的可见性：编译器可能把变量优化进寄存器，任务 B 读到的还是旧值；多核平台上还有缓存一致性问题。这些问题的排查难度呈指数级上升。

正解是用 RTOS 提供的同步与通信原语，而不是自己发明轮子。我把常见的机制分两类：护资源的（互斥锁、信号量），传数据的（消息队列、事件标志组）。

4.2 队列、信号量、互斥锁的选型原则

消息队列本质是一段有序的缓冲区，任务 A 往里写数据块，任务 B 排队取出。它的核心特性是"数据搬运"：把数据从一个任务的内存空间拷到另一个任务的接收缓冲区，天然解耦生产者和消费者。注意队列拷贝是有时间成本的，如果你传的是一整块大数组，频繁拷贝会吃掉不少 CPU，这时候可以考虑只传指针，但传指针要确保指针指向的内存生命周期可靠。

信号量分二值信号量和计数信号量。二值信号量就像一个"事件通知牌"：某个条件发生了，就 give 一下，等着的任务被唤醒。计数信号量则像"令牌桶"，可以累计多次事件，适合统计"发生了几次"这种场景。

互斥锁用于保护共享资源，同一时刻只允许一个任务持有。它比二值信号量多一点额外的机制，比如优先级继承，用来缓解优先级反转。选型时别搞混：需要传数据，用队列；需要通知事件，用信号量；需要保护一块共享数据不被并发读写，用互斥锁。三者场景不同，不能无脑互换。

还有一个容易被忽略的点：同一个互斥锁如果被不同优先级任务竞争，正确做法是把持锁时间压到最短——只是读取或修改一个变量、发一条指令就解锁，千万别在锁的保护范围内做耗时运算、刷屏、打印日志。持锁时间过长，整个系统的实时性都会被拖垮。

4.3 优先级反转：一个绕不开的经典暗礁

假设系统里有三个任务：低优先级任务 L 持有了一把锁，正在做收尾工作；高优先级任务 H 也想拿这把锁，拿不到，进入阻塞；此时中优先级任务 M 就绪，它抢占了 L 的 CPU。于是局面变成：M 一直在跑，L 被 M 抢占后拿不到 CPU，锁迟迟不释放，H 活活被 M"饿"着等锁。实际结果是优先级最低的 M 在 CPU 上跑得风生水起，优先级最高的 H 却卡住不动，优先级体系名存实亡。

这就是经典的优先级反转。解决手段有两类：优先级继承（低优先级任务持有锁期间，临时继承高优先级任务的优先级，防止被中优先级任务抢占）和优先级天花板（直接把持锁任务的优先级抬到系统最高）。多数 RTOS 的互斥锁默认带优先级继承，你不需要自己实现，但必须理解这个背景。遇到项目里出现"高优先级任务无故被拖慢几百毫秒"这种诡异现象，优先往锁和优先级继承的方向查。

5. 实操落地：创建任务时那些参数到底怎么给

5.1 任务创建五要素：函数、句柄、栈、优先级、参数

主流 RTOS 创建任务的接口大同小异，一般长这样：

task_handle_t my_task_handle; /* 创建任务：入口函数、任务名、栈大小、优先级、入口参数 */ ret = task_create(my_task, "my_task", 2048, 5, NULL);

五个参数，个个有讲究：

• 入口函数：任务函数指针，就是前面说的那个死循环函数。
• 任务名：纯标记用途，主要方便调试器里识别任务，命名别偷懒，一个系统里几十个任务全靠名字找。
• 栈大小：单位是"字节"还是"字"，不同内核约定不一样，必须看官方文档。很多内核栈大小单位是"字"（比如 IAR 环境下按 4 字节对齐），你按字节传，栈直接少 4 倍，创建完一批任务，系统莫名其妙崩。这是最坑的单位陷阱。
• 优先级：数值大小和优先级高低的关系，不同内核甚至相反——有的数值越大优先级越高，有的越小越高。看文档确认，不然你以为的高优先级其实是低优先级。
• 入口参数：传给任务函数的一个无类型指针，可以在创建时把结构体地址传进去，任务里解析后用。注意这个参数指向的内存生命周期必须长于任务本身，别传一个局部变量的地址进去。

5.2 栈大小怎么估：先给保守值，再用工具修正

栈大小估算没有公式能一劳永逸，只能按这三条走：

1. 任务函数内部的局部变量，尤其是数组，全加起来算一算。
2. 函数调用链深度。每层调用都可能压栈返回地址和寄存器。
3. 库函数的隐性开销。printf族函数是最著名的栈杀手，一个格式化输出可能吃掉一两百字节甚至更多，如果任务里要打印日志，栈必须额外预留。

我给出的经验做法是：初期按"局部变量总和 + 2倍余量"估算，比如局部数组加变量大约 200 字节，再加两层函数调用按 100 字节算，先给 512 字节起步。跑起来之后打开内核的栈水位检测功能，观察每个任务的实际最大栈使用量，然后统一调整。切忌一上来精打细算给一个"理论极限值"，实际跑起来还得反复改，反而浪费时间。

栈给少了的表现是：系统跑着跑着随机死机、函数返回时地址错乱、调度异常。这类 Bug 极其难查，所以我强烈建议项目一开始就把栈溢出检测钩子打开，宁可多花一点运行开销，也要在开发阶段把隐患暴露出来。

5.3 优先级分配策略：不是随心所欲

根据我做一些实际项目的经验，任务优先级分配有几个通行的原则：

• 实时性要求最高、时延最敏感的任务给最高优先级，比如电机控制环、通信协议帧处理。
• 频率高但执行时间短的任务给较高优先级，因为它的短小精悍不会对低优先级任务造成长时间饥饿。
• 大块的计算、文件操作、日志这类"慢活"给低优先级，允许它们被频繁打断。
• 性质相同、不互相依赖的任务尽量分配相同优先级，用时间片轮转来均衡 CPU，减少因为优先级差异带来的逻辑复杂度。

还有一个需要主动避开的反模式：为了防止任务饿死，把所有任务都设成高优先级或不设优先级差异。这会直接导致调度器频繁切换、系统开销上升，而且任务运行顺序变得不可预测。优先级存在的意义就是表达实时性差异，抹平差异等于你把 RTOS 用成了裸机。

5.4 任务编写禁忌清单

我把自己踩过和见过别人踩的坑整理成一个清单，每一条都是真金白银换来的：

1. 任务里禁止忙等（空循环），需要等资源就用阻塞式等待接口。
2. 任务里禁止调用阻塞系统的函数，比如某些平台上的fgets、不可重入的库函数。
3. 临界区内（关中断保护的代码片段）禁止调用任何可能阻塞的 API，也禁止做耗时操作。
4. 中断服务函数里禁止调用非从中断调用的 API。几乎每个 RTOS 都有一组"中断安全"专用的接口，比如从中断发信号量、从中断发队列，别混用。
5. 任务函数里不要试图return结束自己，所有退出路径都要通过 RTOS 提供的删除任务接口。
6. 被多个任务共享的全局变量，要么加互斥锁，要么保证读写都是原子的，否则迟早踩雷。
7. 关中断的时间务必短。很多人为了省事，在临界区里放了一大段初始化代码，直接把系统所有实时性都毁了，因为高优先级任务在这段时间里即使就绪也进不来。

6. 常见问题与排查技巧实录

6.1 系统跑一阵就随机死机？先怀疑栈溢出

如果调试器里的死机现场经常莫名停在一个看似毫不相关的函数里，或者程序跑飞后在 HardFault 中断里反复进出，十有八九是某个任务栈溢出了。排查顺序如下：

1. 打开 RTOS 的栈溢出检测选项，挂上溢出钩子函数。一旦哪个任务越界，钩子函数立刻触发，通过串口打印出肇事任务的名称。
2. 把疑似任务栈大小加 30%，看是否稳定。稳定后进一步用内核提供的内存水位统计接口查看该任务实际最高使用量，把栈缩到"实际值 + 合理余量"。
3. 检查任务函数里有没有大数组、深层递归、printf调用。这三个是栈吃穿的最常见元凶。

6.2 低优先级任务永远跑不到？

低优先级任务迟迟不执行，或者执行频率极低，最常见的原因不是调度器坏了，而是高优先级任务"占着茅坑不拉屎"——它在一个非阻塞循环里反复检查某个条件，没检查到也不阻塞，继续循环。这个任务只要不就绪，就会踩在就绪表顶部一直占着 CPU，低优先级任务永远没机会。

排查时可以拉出任务列表，看看哪个任务的运行计数一直增长、其他任务计数纹丝不动。解法是把高优先级任务的"等待"改成真正的阻塞等待（信号量、队列、事件标志），让它没活干的时候就睡觉。

6.3 任务间数据时好时坏、不同步？

当两个任务通过共享变量交互，数据出现"偶尔对，偶尔不对"，而且跟发布时间、负载大小正相关时，基本可以确定是竞态问题。逐个检查：

• 这个共享变量有没有被互斥锁保护？
• 中断里和任务里共享的变量，是否通过关中断或中断安全的写操作保护？
• 如果编译器优化级别很高，有没有用volatile声明共享变量？

一个很容易被忽略的场景是：中断里改了标志位，任务里在主循环里读标志位。这时即便不加锁，只要标志位读取是单字节原子操作，问题也不大；但如果你放的是多字节数组或结构体，就极容易撕裂。建议一律用信号量或者队列来做中断到任务的通信，别用裸变量，省那几个字节不如省几天的排查时间。

6.4 CPU 利用率特别高但没干多少活？

这种症状在刚把大量裸机逻辑迁移到 RTOS 时特别常见。原因通常是两个：要么任务划分过碎，大量时间花在上下文切换上；要么某个任务在忙等，空转喂 CPU。先用内核的 CPU 占用率统计功能看一下每个任务的占比，如果发现切换开销项（内核自身开销）占比很高，就着手合并短小任务、增大同优先级任务的时间片长度；如果发现有任务忙等，就换成阻塞等待。

6.5 常见问题速查表

现象	可能原因	优先排查手段
随机死机/跑飞	任务栈溢出	打开栈溢出检测，查钩子，加大栈
某任务长时间不执行	高优先级任务忙等	查运行计数，看是否出现非阻塞空转
数据偶尔错乱	共享变量竞态	加互斥锁，或改用队列/信号量
响应延迟突然变大	优先级反转或关中断过长	查持锁任务，压短临界区
CPU 占用虚高	任务过碎/忙等	查各任务 CPU 占比，合并任务
创建任务后立即死机	栈大小单位错误	核对文档，确认栈大小是字节还是字

结尾再说点实在的

我个人学 RTOS 最大的体会是，别把注意力全放在 API 背书上，先把"任务状态机"刻进脑子里：一个任务永远只处于运行、就绪、阻塞中的一个状态，阻塞的原因千奇百怪，但调度器只认一条规矩——谁在就绪表里且优先级高，谁就先跑。你在一个任务里等信号量的时候，脑子里应该能自动播放"当前任务阻塞、就绪表刷新、调度器选中新任务"这三幕戏，而不是只看代码表面。

最后分享一个排查习惯：怀疑系统里头哪个任务调度异常时，别急着翻代码，先在调试器里把任务列表全部拉出来看。哪个任务阻塞在哪、哪个任务运行计数疯涨、哪个任务 CPU 占用率异常，全系统一眼看过去，通常比盯着代码猜快十倍。RTOS 给你的不只是一堆 API，更像是一套全局视角的体检设备。把状态机用起来，把任务边界划明白，这个 RTOS 你才算真正入了门。