企业官网建设流程全解析

1. Zephyr 的线程体系从哪里开始

1.1 线程就是 RTOS 里“活着的单位”

我最早是在一个 VxWorks 项目里被“任务”这个词惯坏的，后来切到 Zephyr 上，看文档里满屏的 thread、k_thread_create、K_THREAD_DEFINE，第一反应是“这不就是把 task 改了个名字嘛”。真正写了几轮调度代码之后才发现，Zephyr 的线程模型和 VxWorks 的任务模型虽然都是“可调度的执行单元”，但在创建方式、优先级划分、栈管理、退出机制上差别非常大。如果带着 VxWorks 的惯性去写 Zephyr，第一周基本会被各种奇怪的问题按在地上摩擦。

先说一个最基本的概念：Zephyr 里线程是内核调度器的最小调度单位，每个线程有独立的线程控制块、独立的内核栈和可选的用户栈，有自己的一组寄存器上下文。系统启动后，除了我们自己在应用里创建的线程，内核还会自动准备两个系统线程：Main Thread 和 Idle Thread。这两个线程不是可选项，而是整个 Zephyr 能跑起来的地基。Main Thread 负责跑 main()，Idle Thread 负责在“无事发生”的时候占住 CPU、进低功耗、推进 Tickless 逻辑。很多人忽略它们，却在排查栈溢出、调度卡死、功耗异常时反复栽跟头。

这篇文章我想从头到尾把它捋一遍：Zephyr 线程的优先级到底怎么算，Main Thread 和 Idle Thread 是怎么被创建出来的、内核里怎么运行，以及和 VxWorks 的任务体系一对比，差异到底在哪。适合刚上手 Zephyr、准备做系统移植，或者正从 VxWorks 迁到 Zephyr 的嵌入式开发者。

1.2 线程优先级：最容易记反的一张表

Zephyr 的优先级规则，我准备用一句话先刻进脑子里：数字越小，优先级越高。这一点和 VxWorks 的 0~255 一样，0 是最高。但后面跟着的“协作式”和“抢占式”划分，才是真正容易踩坑的地方。

Zephyr 把线程优先级分成两段：负数部分是协作式优先级，非负部分是抢占式优先级。默认配置下，CONFIG_NUM_COOP_PRIORITIES 通常为 0，CONFIG_NUM_PREEMPT_PRIORITIES 通常是 15，所以默认你能用的应用线程优先级基本都在 0 到 14 这个范围内。负数优先级需要额外配置 NUM_COOP_PRIORITIES 才能使用。数值越低越优先，所以一个优先级为 5 的线程，会被一个优先级为 2 的线程抢占，这一点很直觉。

真正反直觉的是协作式这个词。协作式线程不是“优先级更高”，而是“你不主动让出 CPU，别人就别想抢走”。一旦你用了负数优先级，这个线程就进入了协作式模型：它能跑多久完全取决于它自己调不调 k_sleep、k_yield、k_sem_take 这类阻塞或让出操作。在 VxWorks 里默认是抢占式调度，优先级设好了，高优先级任务随时可以打断低优先级任务。在 Zephyr 里，你要是不小心把一个线程的优先级设成了负数，又忘了让它让出 CPU，系统里其他低优先级线程可能永远跑不上来。

我自己的习惯是：能用非负抢占式优先级，就别轻易碰负数。Zephyr 的协作式机制确实能保证某些关键代码段不被乱抢，但前提是你对每个线程的代码路径都心里有数。否则调试器一停，发现高优先级线程卡在一个 while 里死循环，低优先级线程全部饿死，满脸问号。

1.3 线程控制块、线程栈和内核视角

Zephyr 里每个线程的核心数据结构是 struct k_thread，你可以理解成这个线程的“身份证 + 病历本”。里面记录了线程状态、优先级、栈指针、调度链表的链接节点、事件等待链、退出信息、一些架构相关的寄存器保存区等。这个结构体在静态创建线程时由内核分配在内存里，也可以由我们自己提供。用 K_THREAD_DEFINE 或 k_thread_create 创建线程时，代码里见到的那个 struct k_thread 变量，就是它。

线程栈同样是刚需。Zephyr 对线程栈的对齐要求比较严格，标准做法是用 K_THREAD_STACK_DEFINE 或 K_KERNEL_STACK_DEFINE 宏定义。这两个宏不只是分配一段内存那么简单，它会按架构要求做对齐，还会在没有 MMU 的平台上给栈区域加特殊属性和哨兵位，方便栈溢出检测。不要图省事随手定义一个 uint8_t stack[2048] 塞给 k_thread_create，这一下就会埋下两个隐患：栈可能没对齐，栈溢出检测也形同虚设。

从内核视角看，线程创建之后并不是一直在“运行”，它会在就绪队列、等待队列、挂起列表之间来回切换。Zephyr 的调度器在每次中断返回、锁释放、线程主动让出时都可能发生线程切换。正是这套机制，让 Main Thread 和 Idle Thread 能“轮流上班”，也让我们后面要讲的调试和问题排查变得复杂。

2. 深入 Main Thread：你的 main 函数到底跑在哪里

2.1 Main Thread 是谁创建的

在 Zephyr 里，main() 不是“被 BSP 初始化完随便调一下”的，它跑在一个内核专门创建的线程上下文里。这个线程也叫 Main Thread，它的创建发生在内核启动早期。沿着启动流程看，z_cstart() 会做非常多的板级初始化，然后在某个阶段调用 bg_thread_main()，由它来负责准备 Main Thread 的栈和控制块，最终让内核调度器第一次把控制权交给 main()。

我一开始看源码的时候很困惑，因为 main() 明明是个普通 C 函数，怎么就成了线程入口了。其实在 Zephyr 里，main() 的地址会被包装成一个线程入口函数，绑定到 Main Thread 上。你可以简单理解成：你写的 int main(void) 就是 Main Thread 的线程函数。它能不能长期运行、能不能退出，直接影响整个系统的命运。

这里有个实用结论：如果你在 main() 里 return 了，Main Thread 就变成了退出状态，系统里如果没有其他应用线程，就只剩 Idle Thread 在那空转。很多时候表现是“程序没什么反应了”，但不是崩溃，因为内核还在跑，Idle 还在跑，只是没有业务逻辑在执行了。所以嵌入式 Zephyr 工程里，几乎所有 main() 都是 while(1) 循环或者在里面创建好业务线程之后，让 main 阻塞在一些同步对象上，目的就是让 Main Thread 不退出。

2.2 Main Thread 的优先级和栈大小

Main Thread 不是“特殊线程”，它有自己明确的优先级和栈大小配置。默认情况下，Main Thread 的优先级由 CONFIG_MAIN_THREAD_PRIORITY 决定，默认值是 0。在默认的抢占式优先级范围内，0 是最高优先级，所以 main() 一上来就能把初始化工作做完，不会被其他普通线程打断，这一点其实是经过设计的，保证应用初始化阶段有干净的执行环境。

栈大小由 CONFIG_MAIN_STACK_SIZE 控制。这个值不是越大越好，因为在资源紧张的 MCU 上，Main Thread 的栈是一块真金白银的内存。但也不能拍脑袋给个 512，我见过不少同事从别的 RTOS 迁过来后，在 main() 里放了一个大结构体 + 一个不小的日志缓冲，结果刚进 main 就栈溢出，系统反复重启，查了半天才发现是 CONFIG_MAIN_STACK_SIZE 没调够。

调这个值有几个经验：第一，看编译器的栈占用分析，像 Zephyr 的 build 目录里会生成一些 map 文件和栈使用报告；第二，直接把 CONFIG_MAIN_STACK_SIZE 临时调大，在板子上跑一遍高负载场景，再用内核提供的 shell threads 命令看实际峰值栈使用；第三，如果 main() 里只是做初始化然后创建线程，给 1024 或 2048 基本够用，但如果你在 main() 里用了 printf 且开了较多日志后端，栈消费会明显上涨，建议至少留 30% 余量。

2.3 Main Thread 的职责边界

Main Thread 在启动阶段承担着“把所有业务初始化起来”的职责。你可以在 main() 里做板级外设初始化、启动网络协议栈、创建各个业务线程、建立队列和信号量。但一旦初始化完成，我建议尽量别让 Main Thread 继续做耗时或阻塞过深的工作。为什么？因为 Main Thread 的优先级是 0，在默认配置下比绝大多数业务线程都高，如果它一直在跑一个高耗时死循环，其他线程很难获得 CPU。

有人喜欢用 main() 里的 while(1) 做主循环，然后轮询处理一些事件，这在简单裸机思维里没问题，但在多线程 RTOS 里会削弱系统的实时性。更稳妥的做法是：在 main() 里把业务线程建好，然后用 k_sem_take 或其他同步手段挂起 Main Thread，只在需要时才唤醒它。这样 Main Thread 不会占用过多 CPU，业务线程也能按预期调度。

我还踩过一个隐藏坑：想在 Main Thread 里通过 k_thread_priority_set(k_current_get(), 新优先级) 降低自己的优先级，但没查清楚新优先级是否落在有效范围内。Zephyr 对优先级范围有严格校验，你设了一个超出配置范围的数值，初始化时直接断言失败。后来我的做法是，把这种“动态改优先级”的需求尽量收敛到设计阶段，不要在生产代码里频繁改，除非你非常清楚调度器会怎么反应。

3. 深入 Idle Thread：CPU 没事干的时候发生了什么

3.1 Idle Thread 从哪来，为什么必不可少

每个 RTOS 都必须回答一个问题：就绪队列里一个线程都没有，CPU 该干嘛？Zephyr 的答案是 Idle Thread。这个线程由内核在启动阶段自动创建，优先级被放在整个系统的最低端，比所有用户线程都低。也就是说，只要还有任何一个可运行的应用线程，Idle Thread 就没有机会执行。

Idle Thread 的存在不只是为了“占位”，它负责两件大事：一是提供一个让 CPU 进入低功耗模式的机会，二是适配 tickless 时钟机制，避免系统在没有任务时需要每毫秒醒来一次。你可以把 Idle Thread 想象成员工都下班后的保安，平时看不到人，但一旦没人了，他就要开始巡逻、关灯、省电。

很多刚从裸机转过来的朋友会问：既然 Idle Thread 优先级最低，它是不是只在系统“卡死”的时候跑？不是的。当所有业务线程都在等待某个事件，例如等待信号量、等待消息队列，等待队列里可能没有可运行的线程，此时调度器就会切到 Idle Thread，直到某个中断唤醒了业务线程。所以 Idle Thread 被执行，是系统健康的正常状态，不是异常。

3.2 Idle Thread 与 Tickless、电源管理

Zephyr 的 Idle Thread 会调用架构相关的 idle 例程，通常是 CPU 的 halt 或 wait-for-interrupt 指令。在启用 CONFIG_TICKLESS_IDLE 的平台上，Idle Thread 会把系统定时器停下来，直到下一个最早需要处理的定时器到点。这个机制听着高级，本质就是“既然没人要 CPU，那我把心跳也停了”，从而大幅降低功耗。

这块特别容易有一个误解：Tickless 不是所有场景都省电，它适合大多数时间都在睡眠的 IoT 设备。如果你的系统每 10 毫秒就要处理一次通信，Tickless 带来的收益有限，反而可能因为频繁重新配置定时器增加开销。选不选用 tickless，要看你真实的唤醒频率和定时精度需求。

另外，Idle Thread 里执行的代码路径对所有驱动都是可见的。有的驱动在进入低功耗时会关闭外设时钟，如果某个中断恰好在这之后到来，驱动就得保证能正确恢复现场。很多低功耗 bug 都出在这个流程里，比如外部唤醒中断触发了，但外设时钟还没恢复，读寄存器全部读到 0，表现出来就是“不定期死机”。真排查起来，我建议先在 prj.conf 里关掉 tickless，如果问题消失，基本就能锁定是 Idle/Tickless 和驱动配合的问题。

3.3 别在 Idle Thread 里塞私活

Idle Thread 理论上是一个普通线程，用户代码也能拿到它的线程对象。我看到过有些“聪明”的工程师，为了利用 CPU 的“空闲时间”，往 Idle Thread 里挂一些后台任务，比如日志落盘、统计累加。这个做法看着能榨干 CPU，实际上很危险。

因为 Idle Thread 的优先级最低，它总是在系统完全空闲时才运行，你把一段耗时的计算丢进 Idle Thread，一旦某个业务线程短暂可运行，Idle Thread 立刻被打断。如果你在 Idle Thread 里做非原子操作，比如处理一个需要连续多步更新的大结构体，业务线程中断后读到的可能就是中间状态。更麻烦的是，Idle Thread 要负责进入低功耗模式，你塞了耗时任务进去，低功耗流程就被推迟，功耗数据会变得很难看。

正确的姿势是：真正需要后台处理的工作，单独创建一个低优先级抢占线程，把优先级设置到业务允许的最低档，再用消息队列或信号量和它通信。要让 Idle Thread 只扮演“系统无人运行时的最低兜底 + 低功耗入口”这两个角色，别贪心。

4. 线程生命周期、创建方式与调试手法

4.1 线程状态机：就绪、运行、阻塞、挂起、退出

聊完两个系统线程，还得把 Zephyr 的全部线程状态串一遍，不然遇到问题都不知道该看哪里。Zephyr 的线程状态大体分为：就绪、运行、阻塞（含休眠）、挂起、退出。

“就绪”指的是线程具备运行条件，在调度器的就绪队列里排队。“运行”则是 CPU 正在执行它。单核 MCU 上同一时刻只有一个线程运行，但 Zephyr 支持 SMP，多核情况下可以有多个运行线程。“阻塞”通常是因为线程主动等待某个内核对象，例如等待信号量、等待消息队列、调用 k_sleep 延时。阻塞状态的线程不会占用 CPU，它会进入对应的等待队列。

“挂起”和“阻塞”不一样。挂起更像是外部强制让它原地待命，不会因为等待的事件到了就自动恢复，必须有人调用 k_thread_resume 才会继续。这个机制在调试和某些同步场景里非常有用。“退出”则是线程函数返回或被 k_thread_abort 主动终止后的状态，退出后的线程对象一般不能再被调度，除非重新初始化。

排查问题时，看到线程卡在某个状态，不要只看“它没跑”，要区分它是主动阻塞等待还是被挂起。我经常在 Zephyr shell 里用 threads 命令，看一眼每个线程的状态字段，很快就能判断出是不是某个线程忘了 release 信号量，导致其它线程全部阻塞。

4.2 创建线程的几种姿势

Zephyr 创建线程最常见的是两种：静态创建和动态创建。静态创建用 K_THREAD_DEFINE 宏，直接在编译期就排好线程控制块和栈，适合数量固定、启动就需要的线程。动态创建用 k_thread_create，在线程创建前先自己定义栈和控制块，然后用运行时参数初始化。这里的“动态”指的是运行时创建，不是像 Linux 那样可以从堆里随便 new 一个线程。

看一个标准的静态创建例子：

#define MY_THREAD_PRIORITY 7 #define MY_THREAD_STACK_SIZE 1024 void my_thread_entry(void *p1, void *p2, void *p3); K_THREAD_STACK_DEFINE(my_thread_stack, MY_THREAD_STACK_SIZE); struct k_thread my_thread_data; void my_thread_entry(void *p1, void *p2, void *p3) { while (1) { // 业务代码 k_sleep(K_MSEC(100)); } } void main(void) { k_thread_create(&my_thread_data, my_thread_stack, K_THREAD_STACK_SIZEOF(my_thread_stack), my_thread_entry, NULL, NULL, NULL, MY_THREAD_PRIORITY, 0, K_NO_WAIT); k_thread_name_set(&my_thread_data, "my_thread"); }

如果你用 K_THREAD_DEFINE，可以更简洁：

K_THREAD_DEFINE(my_thread_id, MY_THREAD_STACK_SIZE, my_thread_entry, NULL, NULL, NULL, MY_THREAD_PRIORITY, 0, 0);

注意 k_thread_create 的参数里，第一个是线程控制块指针，第二个是栈起始地址，第三个是栈大小，中间三个是传给线程入口的参数，再往后是优先级、创建选项、延时。栈大小最好用 K_THREAD_STACK_SIZEOF 宏取，避免手算数组长度出错。

4.3 用 Shell、West 和 VSCode 观察线程

线程写好了，怎么确认它真的在跑？Zephyr 最实用的工具是 shell。在 prj.conf 里开 CONFIG_SHELL=y，再把串口后端打开，然后启动系统，在串口终端里输入 threads，就能看到所有线程的优先级、状态、栈使用率。这个命令对于定位堆栈问题简直是刚需。

举个例子，你会看到类似这样的输出，每行对应一个线程：线程名、线程对象地址、优先级、状态。如果某个线程栈使用率超过 90%，说明它的栈余量已经很危险，最好赶紧调大。main 线程和 idle 线程都会出现在这个列表里，这也再次证明它们是普通但有特殊职责的系统线程。

习惯 VSCode 的朋友，可以配置 Cortex-Debug 插件，配合 west debug 和调试器，直接图形化看当前线程。Zephyr 在 GDB 侧也有一些辅助宏，能打印线程列表。不过说实话，日常问题用 shell 的 threads 命令效率最高，只有在分析死锁、寄存器上下文异常时才需要开调试器单步。

如果你发现 shell 输出没有线程名，记得在 prj.conf 里设置 CONFIG_THREAD_NAME=y。线程名不只是在 shell 里好看，它还会被很多调试工具用来区分线程，开协议栈和驱动调试日志时尤其有用。

5. VxWorks 任务模型与核心对比

5.1 VxWorks 的任务创建和优先级

VxWorks 里没有“线程”这个词，它叫 Task。最经典的任务创建接口是 taskSpawn，一个函数直接把任务创建出来并放入就绪队列：

int taskId; taskId = taskSpawn("myTask", 100, VX_FP_TASK, 0x2000, (FUNCPTR)myEntry, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);

taskSpawn 的参数非常多，依次是任务名、优先级、选项、栈大小、入口函数、最多 10 个入口参数。这里优先级 100 是 VxWorks 很常见的默认值，范围是 0~255，0 最高，255 最低。VxWorks 默认的调度方式是“基于优先级的抢占式调度”，高优先级任务一旦就绪，会立刻抢占正在运行的低优先级任务。

VxWorks 也支持时间片轮转，但默认不启用，需要显式调用 kernelTimeSlice 或者配置项开启。这一点和 Zephyr 的默认行为不同，Zephyr 的时间片机制更细，可以按优先级段分组，也能用 k_sched_time_slice_set 动态调整。所以如果你从 VxWorks 迁到 Zephyr，不要想当然地认为“我设了优先级，系统就会抢占”，要先确认这个线程是不是协作式优先级。

5.2 VxWorks 里的 Main 和 Idle 怎么理解

VxWorks 的启动流程和 Zephyr 不太一样。VxWorks 镜像启动后，最先执行的是板级 BSP 初始化，之后会进入 usrRoot 这个根任务，在根任务里做各种内核初始化，最后调用用户初始化函数。在很多 VxWorks 工程里，main 并不是系统的固定入口，而更像一个“用户代码入口”，由启动脚本或用户初始化任务来触发执行。

VxWorks 也有一个空闲任务，叫 tIdleTask，它通常以系统最低优先级 255 运行，专门占住 CPU 的空闲时间。和 Zephyr 的 Idle Thread 类似，VxWorks 的 idle task 会调用低功耗指令让系统休眠，但 VxWorks 的功耗管理远没有 Zephyr 的 tickless 那么细。更直白的对比是，Zephyr 把“哪些外设可以睡、何时睡、何时醒”都纳入了系统级电源管理框架，而 VxWorks 传统上更关注硬实时调度，低功耗策略留给开发者自己处理。

在 Main Thread 的差异上，Zephyr 把 main 设计为一个正式的系统线程，有优先级、有栈、有生命周期，你可以修改它的优先级，也能在 shell 里看到它。VxWorks 的 main 更多是“碰巧叫 main 的函数”，没有统一的线程属性，它在哪个任务的上下文里跑，取决于你怎么启动它。理解了这一层差异，你就明白了为什么 VxWorks 老工程师总喜欢把所有初始化丢给 usrAppInit，而不是依赖 main。

5.3 对比表：Zephyr 线程 vs VxWorks 任务

这张表是我个人迁移代码时最常对照的。很多“为什么我在 VxWorks 上好端端的代码到 Zephyr 上顺序不对”的问题，最后都能回溯到调度模型差异上。比如你在 main 里创建完线程后 VxWorks 可能按优先级立刻抢占，而 Zephyr 里 main 本身优先级是 0，初始化阶段其他线程根本跑不上来，看到的现象就是“业务线程迟迟不执行”。

5.4 迁移时的三个思维转换

第一个转换：VxWorks 的动态 taskSpawn 很顺手，但 Zephyr 更推荐静态 K_THREAD_DEFINE。静态定义能把线程栈和线程控制块放到固定段，避免堆碎片问题，也更利于 MPU 保护。除非线程数量运行时变化，否则尽量静态。

第二个转换：VxWorks 的时间片默认关，Zephyr 的时间片配置却常常有人忘记调。在 Zephyr 里如果两个同优先级抢占式线程都需要长期运行，你不开时间片，其中一个可能会一直霸占 CPU，导致另一个“看起来没启动”。开时间片的方法是设置 CONFIG_TIMESLICE_SIZE 或在代码里 k_sched_time_slice_set。

第三个转换：VxWorks 团队习惯用 taskPrioritySet 在运行时调优先级，Zephyr 虽然也有 k_thread_priority_set，但不是所有场景都好使。特别是协作式线程的优先级改了之后，能不能真正抢占当前线程还取决于当前线程是否会主动让出。建议迁移时把“依赖运行时调优先级”改成“用不同同步对象 + 等待机制”，更符合 Zephyr 的习惯。

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

6.1 为什么我的 Main Thread 栈又爆了

这是一个出现频率极高的问题。症状是：程序跑了一会儿，Log 里可能没明显提示，但系统突然复位，或者某些变量被莫名改写。排查方向很明确：先确认是不是 Main Thread 栈溢出。

Zephyr 自带栈溢出检测，前提是 CONFIG_ASSERT、CONFIG_THREAD_STACK_INFO 和相关检测开关开启。打开后，线程栈被写穿时会触发错误或输出调试信息。如果你看到错误指向某个线程，先去 prj.conf 调高对应栈大小。Main Thread 的栈就是 CONFIG_MAIN_STACK_SIZE，别手软，初始化代码里如果用了较重的 printf、JSON 解析、日志缓冲，一次性给到 2048 或 4096 是正常的。

我踩过最隐蔽的一次，是 main() 里没有明显大局部变量，但通过一个回调函数打印了一长串日志，日志格式化里又用了变长缓冲区，直接把 main 线程栈打到溢出。定位时先在关键函数入口处放断点，再用 shell threads 看实时栈峰值，比反复调参可靠得多。

6.2 线程优先级设了，但看着像没生效

优先级设置了，但低优先级线程先跑了，或者高优先级线程迟迟不执行，这种问题多半出在协作式和抢占式混用上。Zephyr 的规则是：负数优先级属于协作式，协作式线程执行期间，除非它主动让出或阻塞，否则即使一个更高优先级的抢占式线程就绪了，也不能打断它。所以看起来就是“我明明设置了一个更高优先级线程，但它就是不跑”。

还有一个常见场景：你把 main 线程用 k_thread_priority_set 调成了负数优先级，然后 main 里写了一个 while(1) 空循环，那所有抢占式业务线程全部被饿死。因为 main 是协作式了，它不主动让出 CPU，调度器拿它没辙。解决办法是在需要让出 CPU 的地方调用 k_yield 或 k_sleep，但最省心的还是不要在生产代码里混用协作式，除非你完全清楚调度图。

6.3 Idle 线程相关的低功耗“假死”

低功耗场景下，系统看起来“死机”，但把调试器一挂，CPU 其实停在 Idle Thread 里，业务线程也没有崩溃。这个问题十有八九是某个外设唤醒中断没配置好，或者中断服务程序里访问了已经掉电的外设寄存器。

排查优先级最高的手段是关掉 CONFIG_TICKLESS_IDLE，把系统强制改成周期性 tick，再看问题是否复现。如果问题消失，说明 Idle Thread 进入 tickless 后，定时器或相关驱动的配合出了岔子。接下来再把 Low Power 相关的驱动逐个摘掉，用二分法定位是哪个外设。

这里有个建议：别在 Idle Thread 里直接调用驱动 API，尤其是带耗时的操作。Idle Thread 是系统最低优先级，任何阻塞都可能卡住低功耗流程。宁可多创建一个低优先级业务线程，用事件标志唤醒，也不要图简单往 idle 里塞代码。

6.4 排查工具和日志技巧速查

我个人最后再分享一个小习惯：在开发阶段，我会强制打开 CONFIG_THREAD_NAME 和 CONFIG_THREAD_ANALYZER，每次启动后都会用 shell 的 threads 命令看一眼所有线程的栈使用峰值。等系统稳定后，再把不必要的调试选项关掉。不要觉得这些配置浪费资源，它们能帮你把“凌晨一点的奇怪 bug”压缩成“下午下班前的一个小配置修改”。线程模型这种事，光看文档永远体会不到坑的深浅，真正上手跑一遍调度，把 Main Thread 和 Idle Thread 的脾气摸透了，后面写业务线程才能顺手。