嵌入式面试到底在考什么：三种常见挂法与 12 个必被追问的方向

《核心观点》

1. 嵌入式面试的核心是「把原理、边界和项目现场连起来」的能力，而不是背题量
2. 面试官在看三层：基础有没有洞、边界清不清、项目能不能扛追问
3. 三种常见挂法：只会背不会用；项目只讲流程不讲问题；简历写太满、实力接不住
4. 以 FreeRTOS 为例的能力分层：会建任务 < 知道队列/信号量/互斥量区别 < 能讲清优先级反转、中断里哪些 API 能用、栈怎么估、真实卡死怎么查 < 能结合项目说清任务划分与选型理由
5. 高频追问方向 12 条：野指针与悬空指针来源、volatile 解决与不解决什么、中断里为什么不能随意延时/打印/拿锁、轮询/中断/DMA 怎么选、临界区做法与代价、队列与信号量/互斥量各自解决什么、优先级反转的成因与缓解、栈溢出的发现与排查、UART 丢数据的软硬件排查、SPI/I2C 卡住的排查顺序、项目里最难 bug 的定位过程、优化如何证明有效
6. 改进方法：每个高频点准备「1 分钟结论版 + 3 分钟追问版」两层答案；每个项目固定讲清架构、你负责什么、一个真难点、怎么验证结果；简历改成可验证表述，少形容词多场景与结果；按目标岗收口（MCU/RTOS 岗盯中断调度总线，Linux 岗补进程线程、驱动、启动链）

《参考解析》

这篇帖子的价值在于它把「评价标准」摆在了前面，而这恰恰是多数人备考时忽略的一层。 嵌入式面试的题面看起来是八股，但面试官的实际目标是验证你的经验密度：一个真正调过 I2C 时序、复现过偶发死机、估过任务栈的人，回答里会自然带上条件、边界和代价；只背过定义的人，一旦被追问第二层就会露馅。所以准备策略不是「覆盖更多知识点」，而是把已经写进简历的那几个点练到能扛两层追问——这个投入产出比比盲目刷新题高得多。

「volatile 解决什么、不解决什么」是这套逻辑最好的样本。 它解决的是「编译器可能把变量缓存进寄存器、导致读到旧值」，用于三类场景：硬件寄存器映射的变量、中断与主循环共享的变量、以及被信号处理或多线程异步修改的变量。它不解决原子性、不解决内存序、也不保证 CPU 层面的缓存一致性。所以「多任务共享变量只加 volatile 够不够」的正确答案是不一定——单核上能保证每次重新读取，但读改写（i++）依然非原子；多核上还需要内存屏障或使用原子操作。能把这三层说清楚，面试官基本就确认你用过而不是背过。

「中断里为什么不能随便延时、打印、拿锁」是另一个分水岭。 中断上下文没有自己的任务栈（或栈很小）、运行在比任何任务都高的优先级上，因此：delay/sleep 会让整个系统停摆且调度器可能不响应；printf 通常带锁且可能阻塞、还会拖长中断时间造成丢中断；拿普通互斥量极易形成「中断等任务释放锁、而任务被中断打断」的死锁。ISR 里应当只做最短的事——置标志、发信号量（FromISR 版本）、写环形缓冲，把处理挪到任务里。这类回答如果顺带说出「中断响应时间的组成（保存现场 + 中断向量表跳转 + ISR 执行 + 恢复现场）」和「长 ISR 会推高系统最大延迟」，就属于能扛第二层了。

「轮询 / 中断 / DMA 怎么选」考的是资源权衡意识。 轮询最简单、无中断开销、延迟可预测，但浪费 CPU，只适合极短等待或高频小数据；中断响应及时、CPU 占用低，但每次有上下文开销，超高频事件下会拖垮系统；DMA 适合大数据量、成块搬运（串口收整帧、SPI 读大块、ADC 连续采样），CPU 只在完成时被通知一次。真正的坑在 DMA 与 cache 的交互：如果外设和 CPU 访问同一块内存，DMA 绕过 CPU 直接读写物理内存，而 CPU 可能读到 cache 里的旧数据（或 cache 尚未回写导致 DMA 读到旧值），必须靠缓冲区对齐、cache 维护（clean/invalidate）或把缓冲放到非 cache 区来解决。这也是「换芯片后为什么必须重新检查」的原因——不同 SoC 的 cache 与一致性设计完全不同。

优先级反转与栈溢出，是两个必须能讲出「怎么发现」的问题。 优先级反转的成因是低优先级任务持有高优先级任务需要的锁、中优先级任务又抢占了低优先级任务，导致高优先级任务被间接阻塞；缓解手段是给互斥量加优先级继承（持有者临时提升到等待者的优先级）、优先级天花板协议，或者干脆避免共享、缩短临界区。栈溢出的发现要靠主动埋哨兵（栈顶填魔数定期检查）、RTOS 提供的栈水位/高水位 API、MPU 边界保护、以及看现象（局部变量被莫名改写、返回地址错乱、HardFault 里 SP 越界）。排查时把栈溢出和其他越界写区分开，靠的是看破坏范围是否贴着栈区、是否只在特定调用深度出现。

「优化怎么证明有效」这一问，很多人答不上，但它是工程能力的直接体现。 有效证明包含三件事：基线与口径（优化前是什么状态、用什么指标衡量、在什么负载下测的）、对照条件（同样的输入、同样的硬件与配置、避免同时改多个变量）、以及统计意义（跑足够多次取分布而不是单次最好值，必要时看 P99 而不只是平均）。交付时给出「优化了 X，从 A 降到 B，在 C 条件下测了 N 次」这种形式的表述，比「感觉快了很多」有说服力的多。