联影嵌入式软件开发一面面经
参加了 联影医疗 嵌入式软件开发一面，整体感受是：问题不多，但每一道都可以“往死里问”。
面试官不会刻意区分 MCU 或 Linux，而是围绕“你是否真正理解系统如何运行”不断追问，从语言本质、硬件行为到操作系统机制，很多问题如果只是停留在经验层面，很容易被继续往底层追溯。
以下是整理出的 18 个问题，基本还原当时的技术深度。
面试题目
- C 语言中一个变量从定义到被 CPU 访问，中间经历了哪些过程？编译器、链接器和内存布局分别做了什么？
- 指针解引用时，CPU 具体做了什么？如果访问了一个非法地址，会在硬件层面发生什么？
- volatile 能解决所有并发可见性问题吗？在多核系统和单核中断场景下分别有什么局限？
- 一个结构体在不同编译器或不同平台下为什么可能布局不同？如何保证跨平台通信时的数据一致性？
- 函数调用过程中，栈帧是如何建立和销毁的？参数传递和返回值在底层是如何实现的？
- 如果出现栈溢出，在 MCU 和 Linux 系统中分别会表现出什么现象？如何检测和定位？
- MCU 上电后，如果中断向量表配置错误，系统会出现什么行为？为什么？
- 中断嵌套是如何实现的？在 ARM 架构中，中断优先级和屏蔽机制是如何工作的？
- 在中断中访问一个全局变量，同时主循环也访问它，如何保证数据一致性？有哪些实现方式，各自代价是什么？
- SPI 通信中，如果主从设备时钟不同步或者出现抖动，数据会如何错误？如何在协议层或驱动层提高鲁棒性？
- I2C 总线如果被某个设备“拉死”（SDA 一直为低），系统如何恢复？有没有通用的处理策略？
- RTOS 中一次任务切换具体保存和恢复了哪些上下文？为什么有些寄存器可以不保存？
- 在高优先级任务频繁抢占的情况下，低优先级任务“饿死”如何解决？有哪些调度策略可以缓解？
- 如果系统中出现偶发性死锁，但无法稳定复现，你会如何设计手段去定位问题？
- Linux 中一次 read 系统调用，从用户态到驱动返回数据，完整路径是什么？涉及哪些关键结构体或机制？
- 如果一个驱动在高并发访问下出现数据错乱，你如何判断是缓存问题、并发问题还是硬件问题？
- mmap 的本质是什么？相比 read/write，它在性能和一致性上有什么代价？
- 如果系统运行一段时间后性能明显下降，但 CPU 利用率不高，你会从哪些角度分析问题？
总结
这次 联影医疗 的一面，核心特点可以总结为三点：
- 问题少但深：几乎每个问题都可以继续向下追溯到硬件或内核层
- 强调系统理解：不仅要知道“怎么做”，还要知道“为什么这样做”
- 贴近真实工程：很多问题直接来源于实际项目中会遇到的复杂场景
准备这类面试，单纯刷题效果有限，更重要的是建立“从代码到硬件再到系统”的完整认知链路，能够把每一个现象解释到机制层面。
查看10道真题和解析