嵌入式项目明明是自己敲的，为什么面试像抄的

《面试题目》

1. 这个数据为什么放在中断里处理？
2. 接收缓冲区为什么定这么大？
3. 如果上位机连续发两条指令，你怎么把它们分开？
4. 这个项目里哪些是你自己写的，哪些是库或例程提供的？
5. 如果采集频率提高、屏幕刷新变慢，程序要怎么改？
6. 串口偶尔丢数据，你怎么定位？

《参考解析》

从「功能复述」转到「设计理由」：能跑通不等于能讲清。面试官问「为什么放中断」「缓冲区为什么这么大」，考的是你有没有做过取舍。中断里处理是为了低延迟和避免丢数据，但 ISR 要短，所以通常只搬数据、置标志，解析放任务；缓冲区大小要按最大帧长、突发流量、RAM 余量和处理延迟估算，太大浪费内存，太小会丢包。每个参数都能说出「为什么是这个值、改大改小会怎样」，项目才像自己的。

沿数据流讲，而不是按代码顺序：从数据从哪个外设进来、放在哪、谁判断完整、谁处理、来不及处理怎么办，一路讲下去。串口接收可以展开成：一次收到的可能不是完整帧，可能半包也可能粘包；程序靠帧头/长度/超时认帧；没收全时数据留在环形缓冲区；解析失败怎么重新同步。沿着这条线翻代码，会发现以前能跑只是因为测试顺序固定、数据长度固定。

主动改需求：检验会不会的办法不是重敲一遍，而是改一点东西：提高采集频率、降低屏幕刷新、支持变长指令、传感器中途拔插。改的时候要拆耦合、检查返回值、处理超时和恢复，这些过程就是面试里最好的素材。改坏了再修好，比「跟着视频实现」更有说服力。

记录 bug：别让「调了很久最后好了」变成唯一记忆。当时什么现象、什么条件出现、先怀疑哪里、做了什么检查、最后改了哪里、是确认根因还是暂时绕过，随手记几句。面试时按「现象—定位—根因—验证—预防」讲，普通项目也能讲出深度。