做嵌入式选型评审的时候，最常吵起来的一个话题就是：这块板子到底该上 RTOS 还是 Linux。做电机控制的同事说 Linux 上跑 1kHz 电流环，抖动大得没法看；做网关的同事说 RTOS 连个像样的文件系统和网络栈都费劲，日志都不知道往哪写。两边说的都对，因为 RTOS 与 Linux 的区别，本质上不是"哪个更好"，而是两种完全不同的设计目标下的产物。这篇内容我想把这两者的差异从内核调度、内存管理、中断延迟、生态成本几个层面掰开讲清楚，中间会给出可以直接复现的测量方法和代码，也会分享一些选型时真正拍板要看的数据指标。适合正在做方案选型的嵌入式工程师、刚接触实时系统的学生，以及需要判断"要不要为了实时性多花一颗芯片钱"的产品负责人参考。

1. 先把概念边界厘清：两者压根不是同一类软件

很多人第一次接触这两个词的时候，会下意识把它们放进同一个抽屉里比较，就像比较两款操作系统哪个"更流畅"。这个前提本身就有问题。Linux 是一个通用分时操作系统，它的设计目标是让尽可能多的任务公平地分享计算资源，追求的是吞吐量和整体体验；RTOS 是实时操作系统，它的设计目标只有一个：保证关键任务在最坏情况下也能在确定的时限内得到响应。这两句话听起来像教科书，但它带来的工程后果极其具体——你在 Linux 上做优化，是让平均延迟变小；你在 RTOS 上做优化，是让最大延迟变小。这两个指标在很多场景下是互相打架的。

我遇到过一个很典型的认知偏差：某开发者拿 Linux 跑了一个 100us 周期的定时任务，用time命令看平均误差只有几微秒，就认为"Linux 实时性够用"。问题在于，实时系统关心的从来不是平均值。跑了八个小时，中间有一次因为内存回收卡了 800us，那一次就足够让电机的 PWM 波形畸变、让通信帧超时重传、让整台设备报故障。RTOS 的价值恰恰体现在那一次上——它的最坏情况是被设计和验证过的，而不是碰运气碰出来的。

还有一个常见误解是"Linux 加个实时补丁就变成 RTOS 了"。这话对一半。实时补丁确实能把 Linux 的调度延迟和中断延迟压下去一大截，工程上很多场景也确实够用了，但它无法消除 Linux 内核里那些固有的不确定性来源：缺页异常、内存回收、缓存与 TLB 行为、驱动里的长临界区。这些不是补丁能彻底解决的，只能缓解。所以业界更准确的说法是"Linux 可以提供软实时甚至硬实时的近似能力，但需要付出额外代价并且要逐项验证"，而不是"Linux 变成了 RTOS"。

1.1 内核体量差了两三个数量级，硬件门槛完全不同

先看一组最直观的数字。一个最小可用的 RTOS 内核，裁剪到只保留任务调度、信号量、消息队列，代码体积可以做到几 KB 到几十 KB，RAM 占用几 KB 就能跑起来。你在只有 32KB Flash、8KB RAM 的入门级单片机上就能跑一个像样的 RTOS。Linux 这边，一个能进命令行的最小系统，内核镜像加工件系统通常要十几 MB 到几十 MB 的存储，运行时 RAM 起步就是十几 MB 到几十 MB，而且几乎必须要有 MMU。

这组数字背后是硬件成本的直接差异。对于年产量几十万台的消费类产品，BOM 上每省一美元都是实打实的利润。一颗带 MMU、能跑 Linux 的应用处理器，加上 DDR、eMMC、电源管理芯片，整套下来比一颗 Cortex-M 级别的 MCU 贵出好几倍。这不是"技术先进不先进"的问题，是商业模型的问题。所以你会看到大量的小家电、电动工具、传感器节点、汽车车身控制器，用的都是 RTOS 甚至裸机循环，不是因为工程师不会 Linux，而是这套方案在成本、启动时间、功耗上就是更优解。

反过来，一旦你的设备需要跑图形界面、需要接 USB 摄像头、需要跑 Wi-Fi 协议栈加 TLS 加密、需要本地存储几个 G 的录像、需要远程升级整个应用，那 RTOS 就开始吃力了。这些功能不是不能做，是每一个都要你自己找移植、自己调、自己扛维护成本。Linux 的生态在这方面的优势是压倒性的。

1.2 启动时间和功耗，是被低估的两个决策因子

启动时间这个指标在车载和工业现场特别致命。倒车影像要求挂倒挡之后一秒内出画面，工业设备要求上电后几百毫秒内进入安全状态。RTOS 从复位向量到主任务跑起来，通常几十毫秒到一两百毫秒，中间还可以把关键外设初始化放在最前面，先把安全相关的输出拉到确定电平。Linux 从引导加载程序到内核解压、设备树解析、驱动探测、根文件系统挂载、init 进程拉起，冷启动一两秒是常态，优化到几百毫秒需要做大量裁剪工作（精简内核配置、用 initramfs、关闭不必要的驱动探测、并行化初始化），而且优化成果很脆弱，加个新设备就可能退回去。

功耗也是类似逻辑。RTOS 的空闲任务可以直接进 deepest sleep，唤醒源和唤醒时间完全可控，因为没有后台进程在偷偷跑。Linux 有一堆常驻服务、有内核线程、有定时器轮询，想做到微安级待机需要相当细致的调优。低功耗传感器节点这个领域，RTOS 加 MCU 的组合短期内看不到被替代的可能。

2. 核心差异逐项拆解：六个维度硬碰硬

2.1 调度器：优先级抢占与完全公平调度的哲学分歧

RTOS 的调度器通常非常简单：每个任务有固定优先级，调度器永远选择就绪队列里优先级最高的那个跑。同优先级任务可以配置时间片轮转，但大多数硬实时场景里，工程师会把优先级设计成严格单调的，保证关键任务的执行顺序完全可预测。这种简单带来两个好处：一是调度决策的耗时是常数级，任务数从 5 个涨到 50 个，切换开销几乎不变；二是行为可分析，你可以用速率单调分析（RMS）之类的方法，在写代码之前就算出这套任务集能不能满足所有截止时间。

Linux 的默认调度器走的是完全公平路线，它维护一棵红黑树记录每个任务的虚拟运行时间，总是挑"欠账最多"的那个执行。这套机制对交互式体验非常友好，桌面环境里点一下鼠标立刻有响应，就是它的功劳。但对实时任务来说，它的行为不好预测——你没法简单地说"我的任务一定在 200us 内拿到 CPU"，因为随时可能有更高优先级的系统行为插进来。Linux 提供了SCHED_FIFO和SCHED_RR两种实时策略绕开 CFS，实时任务可以抢占所有普通任务，但内核里仍有一些不可抢占的区域，这就是实时补丁要解决的问题。

这里有一个很容易被忽略的点：RTOS 的优先级抢占意味着你必须认真设计优先级。优先级排错了，高优先级任务在等低优先级任务持有的锁，就出现了优先级反转，系统直接卡死。成熟的 RTOS 会提供带优先级继承的互斥量来解决这个问题，但很多人图省事直接用二值信号量当锁，就把这个保护绕过去了。这个坑我在项目里见过不止一次。

2.2 内存管理：平坦物理地址与虚拟地址空间的分野

RTOS 通常运行在没有 MMU 的处理器上，所有任务共享同一个物理地址空间。你定义一个全局数组，它的地址在所有任务里都是同一个值；指针传递就是直接传地址，没有地址翻译。好处是开销极低、行为直观、调试简单；坏处是任何一个任务的野指针可以踩烂别人的数据，一个栈溢出可以让整个系统跑飞。这类系统通常靠 MPU（内存保护单元）做粗粒度的区域保护，把任务分成几个特权等级，但隔离强度远不如 MMU。

Linux 依赖 MMU 建立每个进程独立的虚拟地址空间。进程 A 的指针 0x1000 和进程 B 的指针 0x1000 指向完全不同的物理页，互相踩不到。这是 Linux 稳定性的根基，也是它复杂度的来源：每次内存访问都要走页表翻译，TLB 不命中就要多花几十个周期；物理内存不够时内核会做页面回收，把匿名页换到交换分区或者直接丢弃文件页缓存，这个过程可能持续几百微秒甚至毫秒级。

这个差异对实时性的影响是决定性的。你的实时任务正在处理一帧数据，突然触碰到了一个还没映射的页，触发缺页异常，内核要去分配物理页、拷贝数据、更新页表，这段时间你的任务完全停摆。所以 Linux 上的实时程序有一条铁律：实时路径上的内存必须提前锁定。mlockall(MCL_CURRENT | MCL_FUTURE)这行代码几乎是所有 Linux 实时程序的标准配置，它的作用是告诉内核"我这个进程的内存页永远别动"。少了这一行，你的抖动数据就没法看。

2.3 中断与临界区：微秒级和数十微秒级的现实差距

中断延迟是衡量实时性最硬核的指标，它的组成大概是：硬件中断信号到达 → CPU 完成当前指令 → 保存现场 → 进入内核中断入口 → 执行中断服务程序。RTOS 里这套流程被优化到极致，一个跑在几百 MHz 主频的 Cortex-M 上，从中断信号到 ISR 第一条指令执行，通常在几百纳秒到一两微秒之间，而且这个数字是确定的，不会因为系统跑了多久而变化。

Linux 这边的数字要大一个数量级。普通内核里，中断处理过程中会有大段关中断的临界区，最长的关中断时间在几百微秒量级；实时补丁把这些临界区改造成可抢占的，把中断处理线程化，关闭中断的时间能压到几十微秒以内，最坏情况的中断响应延迟可以做到几十微秒。听起来已经很好了，但要注意这是"最坏情况"的统计值，实际表现高度依赖你的硬件平台、驱动质量、负载情况。

我一般会用这样一组经验值来做初步判断：如果你的控制环周期在 100us 以下，或者要求抖动小于 10us，那别犹豫，直接上 RTOS 或者用 MCU 做协处理；周期在 1ms 左右、抖动容忍 100us 量级，实时补丁加持的 Linux 通常能扛住，但必须实测验证；周期在 10ms 以上、容忍毫秒级抖动，普通 Linux 加个高优先级线程就够了。

2.4 可靠性与故障模型：一个跑飞，一个隔离

RTOS 上没有进程隔离，一个任务里的空指针解引用、数组越界、栈溢出，后果往往是整个系统挂掉或者进入不可预期的状态。所以 RTOS 项目的可靠性靠的是另外一套手段：看门狗（硬件独立看门狗 + 任务级喂狗）、栈使用量静态分析、MISRA 之类的编码规范、单元测试覆盖率、以及对所有动态内存分配的禁用或严格管控。

Linux 上一个进程崩了，内核收个 SIGSEGV，把进程回收掉，其他进程照常运行。这种隔离带来的容错能力是 RTOS 很难比的。但 Linux 也不是无敌的，内核态的空指针一样会 panic，驱动写错一样会锁死整个系统，而且排查难度比 RTOS 高得多——你面对的是几百万行代码和复杂的并发模型。

2.5 生态与开发效率：决定项目周期的隐形手

这一项上的差距可能是所有维度里最大的。Linux 上有现成的网络协议栈、文件系统、USB 子系统、图形框架、容器运行时、包管理器、成熟的调试工具链（gdb、perf、ftrace、eBPF）。你想加一个新传感器，驱动框架通常有现成的模板；你想做个 Web 配置界面，起个轻量 HTTP 服务就行；你想 OTA，有成熟的 A/B 分区方案。

RTOS 这边，每一个功能基本都要自己攒。文件系统有轻量级实现，网络有轻量协议栈，但它们的功能完整度和稳定性跟 Linux 上的对应物不在一个量级。更麻烦的是调试手段：RTOS 上你主要靠串口打印、断点、逻辑分析仪，复杂的时序问题排查起来很费劲。Linux 上你可以 ftrace 抓调度轨迹、perf 看热点、bpftrace 做动态追踪，工具丰富度完全不是一个层次。

不过这个优势有前提：你的团队得会用。我见过不少团队为了"生态好"上了 Linux，结果连设备树都没搞明白，驱动调了两个月，最后项目延期比用 RTOS 自己写驱动还严重。生态优势只在会用的人手里才是优势。

2.6 一张表把关键差异固定下来

3. 选型怎么推：拿指标说话，别拿感觉说话

3.1 先算清楚周期、抖动预算和 CPU 利用率

选型第一步不是看别人用什么，而是把你的时间约束写成数字。以一个典型的电机控制加通信的设备为例：电流环 1kHz（周期 1000us），速度环 10kHz？不对，速度环通常 1kHz 或者 100Hz，通信任务 100Hz，再加一个 10Hz 的状态机。假设电流环任务的最坏执行时间是 250us，速度环 180us，通信 400us，状态机 1ms。

先算 CPU 利用率：U = 250/1000 + 180/1000 + 400/10000 + 1000/100000 = 0.25 + 0.18 + 0.04 + 0.01 = 0.48，也就是 48%。这个数看着还行，但 RTOS 上一般建议控制在 70% 以下留出余量，因为还要算中断开销和内核开销。

再算抖动预算。电流环要保证采样和 PWM 更新的时序对齐，通常要求抖动控制在周期的 5% 以内，也就是 50us。这个数字一出来，Linux 普通内核基本出局，实时补丁的 Linux 理论上可行但需要实测确认最坏情况能压到 50us 以内，而且要在满负载、长时间运行、温度变化等条件下都验证。如果实测最坏值到了 120us，那就老老实实上 RTOS。

这里有个容易漏掉的因素：中断延迟会叠加到任务响应时间上。任务的就绪时刻到了，但 CPU 正在处理一个高优先级中断，这个中断的执行时间要算进你的响应延迟里。所以算预算的时候要把最长的中断服务程序时间加进去，而不是只看任务本身的执行时间。

3.2 硬件成本与物料约束往往一票否决

技术方案再漂亮，BOM 超了就是超了。一个带 MMU 的应用处理器方案，除了主芯片本身贵，还要加 DDR 颗粒、eMMC 或者 SD 卡、专用的电源管理芯片、有时还要加 PMIC 的配套电感电容，PCB 层数从四层涨到六层甚至八层，整体成本可能是 MCU 方案的三到五倍。如果产品定价在几十块钱的量级，这个差价基本没法消化。

但反过来算另一笔账：如果因为用了 MCU 方案，你要多花两个月自己写文件系统、调网络协议栈、做 OTA 升级，两个工程师两个月的成本可能比物料差价还高，而且量产后每次功能扩展都要继续投入。这道题没有标准答案，取决于产量、生命周期、团队规模。我的经验是：年产量十万台以下、功能相对固定的产品，MCU 加 RTOS 的综合成本更低；年产量大但功能持续迭代的产品，前期多花点硬件成本换开发效率往往更划算。

3.3 混合架构：现实里最常见的答案不是二选一

真正做过复杂设备的工程师都知道，最实用的方案往往是异构多核。芯片里一颗 Cortex-A 核跑 Linux 负责界面、网络、存储、日志，另一颗 Cortex-M 核跑 RTOS 负责实时控制，两个核通过共享内存加邮箱中断通信。这种架构把两边的优势都吃到了：Linux 那边随便折腾不影响控制环，控制环那边再怎么忙也不会拖慢界面。

核间通信的实现方式是关键。共享内存要划出一块双方都不可缓存或者要做缓存一致性的区域，通常的做法是把这块内存标记为非缓存，或者用带一致性维护的接口收发数据。邮箱中断用来通知对方有新数据。协议上要设计好消息头、长度、校验和序号，防止半包和乱序。业界有现成的框架可以用，比如基于rpmsg的核间通信方案，它把共享内存和中断封装成了类似 socket 的接口，省掉不少底层工作。

这种方案的成本代价是芯片本身更贵，但省掉了一颗独立 MCU 和外围电路，整体算下来在中等复杂度设备上经常是最优解。要注意的是调试复杂度上升了，一个问题可能出在 A 核、M 核、共享内存协议或者硬件链路上，定位起来需要两边同时抓日志。

3.4 团队能力和维护周期是不能忽略的软成本

这一条很少有人写进选型文档，但它经常是决定性的。Linux 的驱动开发、设备树配置、内核裁剪、启动优化，每一项都有不低的学习曲线。一个只做过裸机的团队，第一个 Linux 项目延期半年是常见的事。RTOS 上手快，但生态薄，遇到问题能查到的资料少，很多时候要自己啃源码。

还有一个维度是产品生命周期。工业设备的生命周期动辄十年，十年后你还要能买到芯片、能维护这套代码。Linux 社区活跃、长期支持版本多，但内核升级带来的驱动适配工作量不小；RTOS 相对稳定，但小众 RTOS 的厂商支持可能中断。选型时把"五年后谁来维护这套东西"这个问题问一遍，很多方案自己就出局了。

4. 动手测：把"实时性"这个模糊的词量化出来

4.1 中断延迟的测量方法

测中断延迟最经典的办法是 GPIO 加示波器。做法是这样：用一个外部信号源（信号发生器或者另一块板子的 GPIO）产生一个上升沿，接到目标板的某个中断引脚上；在中断服务程序的第一条语句里翻转另一个 GPIO；用示波器双通道同时看这两个信号，两个上升沿之间的时间差就是完整的中断响应加 ISR 入口延迟。

这个测量里有个细节要注意：编译器优化可能会把 GPIO 翻转的代码挪位置，导致测出来的不是真实的中断入口时刻。稳妥的做法是把翻转操作写成内联汇编或者用volatile指针直接操作寄存器，并且在 ISR 声明上加__attribute__((interrupt))之类的修饰保证它真的是中断入口。另外示波器的探头带宽和采样率要够，测微秒级延迟至少用 100MHz 带宽、1GSa/s 采样的设备。

如果想测的是"从事件发生到任务开始执行"的端到端延迟，那就在 ISR 里翻转一个 GPIO，在目标任务的第一条语句里翻转另一个，两个边沿的差值就是完整链路。这个数字更贴近你实际关心的指标。

4.2 Linux 侧延迟测量的组合拳

Linux 上测延迟最常用的工具是cyclictest，它创建一个高优先级线程，循环做"睡固定时间 → 醒来记录实际时间差"的动作，统计出最大延迟。用法大致如下：

# 单线程，优先级 99，间隔 1ms，跑 100000 次，输出直方图 cyclictest -t1 -p 99 -i 1000 -l 100000 -h 400 -q # 多线程抢核，模拟真实负载下的最坏情况 cyclictest -t4 -p 99 -i 200 -l 200000 -m -n

几个参数值得说明：-p 99是设成最高实时优先级，不设的话测出来的是普通调度下的延迟，没有参考价值；-m是把线程内存锁定，对应前面说的mlockall；-n用 clock_nanosleep 而不是普通 nanosleep；-h 400输出 400us 以内的延迟直方图。

但cyclictest只测了调度和定时器路径的延迟，测不到中断响应。想看关中断时间，用 ftrace 的irqsoff追踪器：

# 找出系统里最长的关中断区间 cd /sys/kernel/debug/tracing echo 0 > tracing_on echo irqsoff > current_tracer echo 1 > options/latency-format echo 1 > tracing_on sleep 30 echo 0 > tracing_on cat trace | head -50

这个追踪器会记录每次关中断的最长持续时间以及当时的调用栈，能直接定位到是哪个驱动、哪段代码拖长了延迟。我排查过一个案例，最大关中断时间来自某个外设驱动的寄存器轮询，改成中断加 DMA 之后，最坏值从 300 多微秒降到了 40 微秒以内。

测量环境本身也要控制：CPU 频率调节器设成 performance，关掉深度睡眠状态，关掉不相关的后台服务，把测试跑够长时间（至少几小时，最好过夜），这样才能捕捉到罕见的最坏情况。测一次两分钟得出的最大延迟，基本没有参考价值。

4.3 一个最小可复现的对比实验

为了把两边的差异直观展示出来，我一般会写两个功能等价的小程序：一个周期任务，每次醒来记录时间戳，计算与预期时刻的偏差，统计最大值和标准差。RTOS 侧用 FreeRTOS 的 API，Linux 侧用 pthread 加 SCHED_FIFO。

RTOS 侧的核心代码如下，重点是创建任务时优先级要给足，并且要在任务开始前把中断优先级分组配好：

#include "FreeRTOS.h" #include "task.h" static volatile uint32_t g_max_jitter_us = 0; static volatile uint32_t g_last_tick = 0; static void periodic_task(void *arg) { TickType_t last_wake = xTaskGetTickCount(); const TickType_t period = pdMS_TO_TICKS(1); for (;;) { vTaskDelayUntil(&last_wake, period); uint32_t now = dwt_get_cycle_count(); /* 直接用 DWT 计数器，精度最高 */ uint32_t jitter = now - g_last_tick; if (jitter > g_max_jitter_us) { g_max_jitter_us = jitter; } g_last_tick = now; /* 实际业务逻辑放这里，注意不要调用阻塞 API */ do_control_step(); } } void app_main(void) { /* 优先级要高于所有非实时任务，栈大小按实测留 30% 余量 */ xTaskCreate(periodic_task, "ctrl", 512, NULL, configMAX_PRIORITIES - 1, NULL); vTaskStartScheduler(); }

这里用 DWT 周期计数器而不是系统 tick 来打时间戳，是因为 tick 的精度本身就是毫秒级，用 tick 测抖动等于用尺子量头发丝。DWT 计数器的分辨率是 CPU 主频的倒数，480MHz 主频下就是 2ns，足够了。

Linux 侧的等价实现要麻烦一些，关键点都集中在开头几行：

#define _GNU_SOURCE #include <pthread.h> #include <sched.h> #include <sys/mman.h> #include <time.h> #include <stdio.h> static void *periodic_thread(void *arg) { struct timespec next; clock_gettime(CLOCK_MONOTONIC, &next); for (int i = 0; i < 1000000; i++) { next.tv_nsec += 1000000; /* 1ms 周期 */ if (next.tv_nsec >= 1000000000) { next.tv_nsec -= 1000000000; next.tv_sec += 1; } int rc = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &next, NULL); if (rc != 0) continue; struct timespec now; clock_gettime(CLOCK_MONOTONIC, &now); long jitter_ns = (now.tv_sec - next.tv_sec) * 1000000000L + (now.tv_nsec - next.tv_nsec); if (jitter_ns > g_max_jitter_ns) g_max_jitter_ns = jitter_ns; do_control_step(); } return NULL; } int main(void) { /* 这三行是 Linux 实时程序的地基，少一行数据就没法看 */ mlockall(MCL_CURRENT | MCL_FUTURE); struct sched_param sp = { .sched_priority = 90 }; pthread_t th; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setschedpolicy(&attr, SCHED_FIFO); pthread_attr_setschedparam(&attr, &sp); pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED); pthread_create(&th, &attr, periodic_thread, NULL); pthread_join(th, NULL); printf("max jitter: %ld ns\n", g_max_jitter_ns); return 0; }

注意这里用的是绝对时间的clock_nanosleep而不是固定延时的usleep。用相对延时的话，每次的误差会累积，跑一会儿周期就漂了；用绝对时间，即使某次睡过头了，下一次仍然按原定时钟点走，不会雪崩。

4.4 实测数据怎么读

在一颗 480MHz 的 Cortex-M7 上跑 RTOS 版本，1ms 周期、CPU 负载 40% 左右的条件下，长时间统计出来的抖动通常是个位数微秒，最大值偶尔到十几微秒，主要来自高优先级中断的插入。这个分布非常"干净"，没有长尾。

在实时补丁加持的 Linux 上，同样 1ms 周期的实时线程，空载时的抖动通常在几十微秒以内，最大值可能到一百多微秒；一旦系统里有磁盘 IO、网络收包、日志写入这些活动，最坏值会明显变大，几百微秒到一毫秒都有可能。这个长尾是 Linux 的固有特征，你可以通过隔离 CPU 核心（isolcpus）、把中断亲和性从实时核上挪走、关掉无关服务来收敛它，但很难彻底消除。

读这些数据的时候，重点看三个数：最大值决定你的方案能不能用，99.9 分位值反映典型工况下的表现，分布的形态反映系统有没有偶发的外部干扰。平均值基本没有参考价值，它会把最坏情况藏起来。

5. 踩坑实录与高频问题速查

5.1 那些文档里不会写的经验

坑一：任务优先级设计反了导致连锁阻塞。有个项目里，日志任务被设成了较高优先级，控制任务反而低一级。平稳运行时没事，一旦日志把串口写满开始阻塞，控制任务的响应时间就被拖长了。这类问题的隐蔽之处在于，它只在特定负载下暴露。判断方法是做一次"优先级审计"：把所有任务按截止时间从紧到松排一遍，和实际代码里的优先级数值对照，凡是顺序不一致的都要给出理由。

坑二：中断里调用了非 FromISR 版本的 API。RTOS 的同步原语通常有两套接口，一套给任务用，一套给中断用。在中断里误用任务版本，轻则断言失败，重则死锁。这类错误编译器不报，只能靠代码审查和运行时钩子函数发现。我一般会在调试版本里打开 RTOS 的断言和栈溢出检测，让这类错误尽早暴露。

坑三：Linux 实时任务忘了锁内存导致抖动爆表。前面提过，这里再强调一次。程序刚跑起来的时候内存都在物理页里，抖动很小，跑久了内核开始回收，实时任务访问到一个被换出的页，就卡住了。加上mlockall之后抖动曲线立刻变平。还有一个相关的坑是把实时任务的数据放在malloc出来的堆上，堆区的页有时候会被内核合并或者做透明大页处理，也会引入不确定延迟。

坑四：CPU 空闲状态拖长唤醒时间。Linux 为了省电会进各种深度 idle 状态，从最深的状态唤醒可能要几百微秒。实时系统里要在内核启动参数里限制最大 idle 深度（idle=poll或者限制cpuidle的 governor），或者至少保证实时核不进入深度睡眠。

坑五：动态内存分配在 RTOS 上埋雷。很多 RTOS 提供的malloc是简单的首次适配算法，跑几天之后内存碎片化，某次分配耗时突然变长或者直接失败。硬实时系统的通行做法是彻底禁用堆分配，所有缓冲区在编译期静态分配，或者用固定大小的内存池（RTOS 通常提供MemoryPool之类的原语）。

坑六：把普通 Linux 的延迟数据当成实时补丁的数据。这两者的差距非常大，而且实时补丁不是所有平台都有良好支持。评估时一定要在实际使用的那块板子上、用最终的内核配置、在满负载条件下测，不要拿开发机上的数据做决策。

5.2 高频问题速查表

选型这件事，我个人的做法是先写下三个数字：控制环周期、允许的最大抖动、整机 BOM 上限。这三个数字写下来，方案基本就收敛了，剩下的都是工程细节。真正难的不是判断哪个技术更先进，而是承认在某个成本约束下，你想要的那个功能就是做不了，然后去找一个能做的方式把它做出来。