面了三十场才发现的规律：一面能答的，二面全在下面那层设卡

《核心观点》

1. 三十场面试挂掉的原因高度一致：卡住的知识点从没变过，只是换人换问法
2. 一面基础题居多、大部分能答上；二面难度明显上台阶，集中在 Linux 内核与调度原理
3. 二面的提问方式不问「会不会用」，直接问「底层怎么实现的」
4. 刷面经时看到一道题觉得「这个我会」就翻页，而那个「会」只是知道它是什么，再往下的怎么实现、为什么这么设计全是空的
5. 这个洞平时自己照不出来，非得面试官顺着追一句才知道
6. 一面高频题清单：volatile 与 static 的作用、字节对齐规则与不对齐的后果、进程与线程及各自通信方式、堆栈区别与内存分配、const 与指针、I2C 通信过程与上拉电阻、DMA 的作用与好处、GDB 常用命令与段错误定位、FreeRTOS 抢占式调度、互斥量与信号量的区别与场景
7. 二面高频题清单：schedule 何时被调用、页表级数与分页缺点、时间片轮转与多级反馈队列及 nice 值、共享内存是否依赖内核、实时调度器设计、信号量释放后唤醒哪个线程、系统实时性评估与中断响应时间测量、上下文切换具体做了什么、MMU 地址翻译、u-boot 两阶段启动

《参考解析》

这篇复盘最有价值的一句是「那个『会』只是知道它是什么」。 这其实是嵌入式面试的核心机制：一面考的是覆盖面（你能不能说出一堆概念），二面考的是纵深（你能不能解释它怎么实现、为什么这么设计、代价是什么）。两者的准备方式完全不同——前者靠刷题和整理清单，后者只能靠读源码、做实验、把每个结论追问到「为什么」。作者「平时照不出来这个洞」的观察也成立：纵深不足的自我感知很弱，因为一个知识点在自测时，你会自然而然地停在自己会的那一层。

二面清单里的题，答法都有共同的落点。 比如「schedule 什么时候被调用」——本质是理解调度时机：主动让出（阻塞的系统调用、sleep、等待锁）、被抢占（时间片耗尽、更高优先级任务唤醒）、以及中断返回前的检查（need_resched 标志 + 抢占点）；关键结论是内核只在特定安全点检查是否需要切换，而不是任何时刻都能换，这解释了为什么「抢占延迟」存在、以及为什么实时内核要打 PREEMPT_RT 补丁。「页表几级、分页有什么缺点」的落点是多级页表用时间换空间：级数越多省内存（不用为整个虚拟地址空间分配页表），但每次地址翻译要多次访存，所以需要 TLB；缺页中断带来延迟抖动，大页（huge page）正是为减少 TLB miss 和页表层级而存在。这类回答的特点是把两个知识点连起来（分页 ↔ TLB ↔ 大页），比单独背定义有说服力得多。

几个容易被问死的点，值得单独记住结论。 共享内存依不依赖内核：mmap 建立映射这一步依赖内核（要系统调用、要内核维护 VMA），但映射建立之后的数据读写完全在用户态、不经过内核，这正是它快的原因——所以「读写不依赖内核、建立映射依赖内核」才是完整答案。信号量释放后唤醒哪个线程：Linux 的互斥量/信号量通常用 FIFO 等待队列（mutex 是乐观自旋 + FIFO 排队），醒来后还要重新竞争；而 futex 的唤醒是按等待队列顺序唤醒指定数量，所以「先来先得」是近似成立但非严格保证（有自旋尝试插队）。上下文切换具体做了什么：保存当前任务的寄存器与栈指针、更新任务结构体状态、选择下一个任务、恢复其寄存器与栈指针、切换地址空间（进程切换才需要刷 TLB/切 CR3，线程切换不用）、以及处理 FPU/SIMD 状态。这些细节能背不能说清，就是典型的「一面水平」。

u-boot 两阶段启动的答案，本质是「先解决一个鸡生蛋问题」。 第一阶段（SPL/MLO）运行在 SRAM 上，因为此时 DDR 还没初始化、代码不能直接跑在外部内存上；它的任务极简——初始化时钟、串口、DDR 控制器，然后把完整的 u-boot 从存储（eMMC/SPI Flash/SD）搬到 DDR；第二阶段在 DDR 里运行，具备完整功能（命令行、网络、文件系统、镜像校验与引导）。所以第一阶段要尽量小的原因是 SRAM 容量有限（几十到几百 KB）且它是唯一的落脚点，代码必须塞得进去。这个「受限于 SRAM」的约束，是把两阶段设计讲清楚的关键。

关于「实时性怎么评估、中断响应时间怎么测」，答案是量最坏情况而不是平均。 实时系统的关键是最坏情况执行时间（WCET）与最坏响应时间（WCRT），因为一次超时就可能造成安全事故。测量手段有：硬件 GPIO 翻转 + 示波器打点（最准，能测到微秒级以下）、CPU 的周期计数器（DWT CYCCNT）打点、cyclictest／ftrace（irqsoff、preemptoff tracer）测中断与抢占延迟、以及压力测试下取分布（看 P99.9 而不是平均）。评估一个系统的实时性还要看调度策略是否确定（抢占式优先级调度 + 优先级继承）、关中断时长、是否有不可控的延迟源（内存分配、页错误、cache miss、DMA 争用、SMI）。这套「最坏 + 分布 + 压力」的方法论，比背几个 API 更能体现工程素养。

这篇复盘最后一句点出的问题，也适用于非嵌入职位的准备。 「一面那些八股我是跟着文章过的，但二面这种深度它救不了我，还是得自己啃内核」——把这个结构抽象出来就是：任何技术方向的面经都只能覆盖广度，纵深必须靠一手材料（源码、文档、实验）。可操作的替代方案是「一个知识点只深挖一次但挖到底」：挑自己简历上真的用过的那三五件事，把每个都追问到「怎么实现、为什么这么设计、代价是什么、出问题怎么排查」，把答案写成两层（1 分钟结论版 + 3 分钟追问版）——这恰好是这篇帖子自己给出的改进方向。