2026 嵌入式面试热点：Linux、RTOS、驱动、MCU 到项目深挖，准备主线其实已经很清楚了

很多人复习嵌入式面试时，容易在资料堆里来回切换：今天刷 C 语言，明天看 Linux 驱动，后天补 FreeRTOS，最后又发现面试官真正想看的并不是你背过多少知识点，而是你能不能把底层基础、调试能力、工程经验和项目表达连成一条线。

从近阶段岗位要求和面试交流内容里能明显看出来，嵌入式岗位的筛选标准正在收紧。只会停留在单片机外设调用、只会背八股、只会说“做过串口通信”的候选人，区分度越来越低。真正更容易拿到面试通过感的，是那些既能讲清楚 C/C++ 基础，又能落到 Linux/RTOS/BSP/驱动/协议/调试/项目闭环的人。

如果把现在常见的面试方向压缩成一句话，就是：基础要硬，系统观要有，项目要能深挖，问题定位过程要讲得出来。

为什么今年的面试越来越看“系统化能力”

很多嵌入式岗位表面上写的是 MCU 开发、Linux 开发、驱动开发、BSP 开发、应用开发，但面试过程里的考察边界并不完全按岗位名字划分。

做 MCU 的，依然会被追问中断优先级、启动流程、内存分区、DMA、定时器、通信异常定位，甚至会被问到任务调度和临界区处理。做 Linux 的，不只是考 select/poll/epoll、进程线程和内存管理，也会追到字符设备、平台总线、设备树、同步机制、用户态与内核态交互。做 RTOS 的，除了任务、队列、信号量、互斥锁，往往还要说清楚抢占、优先级反转、ISR 与任务协作，以及系统卡死时怎么排查。

这背后反映的其实是同一个判断：面试官不太在意你是否背过一整本书，更在意你能不能面对一个真实系统，把问题拆开、定位、解释并收敛。

第一条主线：C/C++ 不是开胃菜，而是整个技术栈的地基

不少人一提嵌入式准备，就急着往 Linux 驱动、协议栈、RTOS 调度上冲，结果在最基础的环节先失分。C 语言和 C++ 在嵌入式面试里从来都不是“送分题”，它们反而决定了后续追问能追多深。

常见高频点依然很稳定：指针与数组、函数指针、结构体对齐、大小端、volatile、const、宏与内联、堆栈区别、内存泄漏、野指针、回调机制、链表、环形队列、位运算。到了 C++，又会延伸到对象模型、虚函数、虚表、多态、继承、RAII、智能指针、引用与右值语义，甚至模板在嵌入式工程里的边界。

面试真正拉开差距的地方不在定义，而在落地场景。比如为什么寄存器映射地址常配合 volatile？为什么中断上下文里不建议做复杂内存分配？为什么环形缓冲区比链表更适合某些串口接收场景？为什么一个回调注册接口设计不当，后面就会带来生命周期和线程安全问题？

基础回答一旦能自然过渡到工程语境，面试官就会默认你不是死记硬背型选手。

更加全面的嵌入式面试八股文和大厂面试题都整理在专栏了：

https://www.nowcoder.com/creation/manager/columnDetail/mPZ4kk

第二条主线：Linux 方向的考察已经从“会用”转向“懂链路”

Linux 仍然是当前不少中高含金量嵌入式岗位的核心筛选器。这里的难点不只是点多，而是问题之间彼此相连。进程线程、调度、虚拟内存、文件系统、网络、驱动模型、设备树、同步并发，看起来是不同模块，但面试里经常会被串成一条链。

典型追问方式通常长这样：用户态程序访问某个设备节点，底层驱动如何注册？open/read/write/ioctl/mmap/poll 经过了哪些路径？阻塞和非阻塞差异是什么？设备中断来了之后，上半部和下半部怎么配合？如果数据吞吐上不去，是应该先看拷贝次数、等待机制、中断频率，还是锁竞争？

很多候选人在 Linux 面试里最大的问题，是每个知识点都能说一句，但连不起来。真正更有说服力的表达，是能够从应用层请求一路讲到内核接口、驱动回调、硬件中断、缓冲区设计、唤醒机制，再回到用户态如何读取和超时控制。哪怕你做的不是完整驱动，只要你能把链路说清楚，认可度也会明显提升。

另外一个越来越高频的方向是设备树、BSP 和启动流程。很多团队不要求新人从零移植一套 Linux，但会很在意你是否理解 bootloader -> kernel -> rootfs -> driver probe -> app startup 这条启动主线。会不会改设备树，会不会看启动 log，会不会定位 probe 失败，会不会处理 pinctrl、时钟、GPIO、中断号配置，这些问题都很容易成为加分项。

第三条主线：RTOS 面试看的是“实时性 + 并发控制 + 稳定性”

RTOS 的知识点看起来比 Linux 少，但面试反而常常问得更细。原因很简单：RTOS 通常更贴近实时业务，一旦并发模型没处理好，问题会直接变成丢包、超时、死锁、喂狗失败、系统重启或者偶发卡死。

任务调度只是起点。更关键的是你要能说清楚什么时候该用任务通知，什么时候该用队列，什么时候信号量只是同步而不是数据传递，互斥锁为什么能处理优先级继承，临界区和关闭中断分别适合什么场景，ISR 里哪些 API 能调，哪些不能调。

如果项目里用过 FreeRTOS、RT-Thread、ThreadX、uc/OS 或厂商 RTOS，面试官基本都会继续问栈大小怎么定、任务优先级怎么分、CPU 占用率怎么观察、堆内存怎么管理、定时器漂移怎么处理、任务卡死时怎么抓现场。这里真正重要的不是 API 名字，而是你有没有稳定性意识。

说得再直接一点，RTOS 面试里最有价值的经验通常来自故障现场，而不是函数手册。

第四条主线：驱动、BSP 和协议题，已经不满足于“知道接口”

驱动/BSP/协议类问题现在非常容易被连环追问，因为它们最能区分“看过资料”和“干过工程”。

以通信协议为例，UART/SPI/I2C/CAN/USB/Ethernet 经常一起出现，但问法通常不会只停留在时序定义。面试官更想知道的是：主从关系如何影响驱动设计？DMA 何时能显著减轻 CPU 压力？总线异常时你怎么恢复？I2C 仲裁失败、SPI 丢时钟、UART 粘包、CAN 仲裁冲突、网口收发异常，分别怎么定位？如果板子上协议能跑但偶发出错，你第一步看波形、log、寄存器还是线程时序？

BSP 方向则常常围绕板级初始化展开。时钟树、引脚复用、启动文件、链接脚本、内存映射、cache、MPU/MMU、外设初始化顺序、看门狗、低功耗唤醒，这些内容在项目里平时容易被封装起来，但一到面试就要重新拆开说。尤其是做 STM32、NXP、TI、瑞萨、全志、瑞芯微、海思这类平台相关开发的人，往往会被追着问启动阶段到底发生了什么，系统为什么卡在某一步，如何证明不是硬件问题。

协议题和 BSP 题的高分答案，一般都带有明显的“问题定位路径”。