嵌入式面试：从玩具级到工程级，STM32与Linux工程闭环设计

1. 面试官眼里的“玩具级”和“工程级”到底差在哪

很多做嵌入式开发的朋友都有过这种困惑：自己用 STM32 做过平衡车、用 Linux 跑过摄像头推流，简历上项目列了满满一页，结果面试官扫两眼就开始问“你这个东西量产过吗”“异常情况怎么处理的”，几个回合下来就被定性成“玩具级”。问题不在于你用的芯片不够高级，也不在于你做的功能不够花哨，而在于你的项目里缺少一条完整的工程闭环。

所谓工程闭环，说白了就是你的系统从“能跑起来”到“能稳定交付”之间，所有该考虑的事情你都考虑到了，并且有对应的设计、代码和验证手段。玩具级项目的特点是：功能实现了，演示视频拍得挺好看，但一旦追问边界条件、异常恢复、资源约束、可维护性，就答不上来。工程级项目的特点是：功能只是冰山一角，水面下藏着状态机设计、错误处理、日志体系、参数管理、升级机制、测试验证这一整套东西。

我见过太多候选人，简历上写着“基于 STM32 的智能家居网关”，一问通信断了怎么办，回答“重启一下”；再问重启期间数据丢了怎么办，就卡住了。这种回答在面试官心里直接扣到“玩具”那一档。反过来，哪怕你做的只是一个简单的温控器，但你能说清楚看门狗怎么喂、Flash 磨损怎么均衡、掉电前怎么保存关键状态、固件怎么差分升级，面试官就会认为你具备工程思维，值得给到 30K 以上的价位。

这篇文章就是要把“工程闭环”这件事拆开揉碎讲清楚。我会从项目架构设计、核心细节实现、完整实操流程、常见问题排查四个维度，结合 STM32 和 Linux 两个平台的实际场景，告诉你面试官到底在考察什么，以及你怎么在自己的项目里把这条闭环补上。不管你是刚入行的新手，还是做了几年想往上跳的工程师，这些内容都能直接拿去对照自己的项目做查漏补缺。

2. 工程闭环的整体设计思路与选型逻辑

2.1 为什么“功能实现”只是闭环的起点

很多开发者的思维惯性是：需求来了，画个框图，选个芯片，写代码，调通，交付。这个流程在学校的课程设计里没问题，但在工业场景里，交付才是麻烦的开始。设备装到现场，电磁环境复杂，电源可能不稳，通信可能丢包，用户可能乱操作，这些都不是“功能实现”能覆盖的。

工程闭环的核心思路是：把系统当成一个会出错的实体来设计。你要假设通信一定会断、电源一定会掉、Flash 一定会写坏、传感器一定会返回异常值。然后针对每一种假设，设计对应的检测、恢复和记录机制。面试官问“通信断了怎么办”，他真正想听的不是“重启”，而是你有没有一套分层的错误处理策略：底层驱动检测到超时，中间件触发重连状态机，应用层决定是缓存数据还是降级运行，同时日志系统记录事件供事后分析。

这个思路的转变，是从“写代码”到“做系统”的分水岭。STM32 上的裸机程序也好，Linux 上的多进程应用也好，底层逻辑是一样的。区别只在于 Linux 提供了更丰富的系统调用和进程隔离机制，你可以用信号、守护进程、系统日志这些现成工具；而 STM32 上你可能需要自己实现一套轻量级的错误码体系和状态机框架。

2.2 STM32 与 Linux 两条技术路线的闭环差异

STM32 和 Linux 在工程闭环上的侧重点完全不同，面试官考察的维度也不一样。STM32 项目通常资源受限，没有操作系统或者只跑 RTOS，所以面试官关注的是你对裸机资源管理的理解：中断优先级怎么分配、堆栈怎么估算、看门狗怎么设计、低功耗模式怎么切换。Linux 项目通常资源相对充裕，但系统复杂度高，面试官关注的是进程间通信、并发控制、系统稳定性：多线程怎么同步、共享内存怎么保护、守护进程怎么设计、系统日志怎么分级。

我整理了一个对照表，方便你快速定位自己项目所在的平台需要重点补哪些闭环环节：

这张表不是让你每个格子都填满，而是提醒你：面试官问“你这个项目怎么保证稳定”的时候，你至少要在自己平台的对应列里有话说。STM32 候选人如果能把看门狗和 Flash 日志讲清楚，Linux 候选人如果能把守护进程和日志分级讲清楚，就已经超过大部分竞争者了。

2.3 从“能演示”到“能交付”的关键跨越

我观察到一个很普遍的现象：很多开发者把“演示成功”当成项目完成的标志。演示的时候环境是理想的，电源是稳定的，网络是通畅的，操作是规范的。但真实场景里，这些条件一个都不成立。从演示到交付，你需要补上三件事。

第一是异常路径的覆盖。正常路径的代码可能只占 30%，剩下 70% 都在处理各种异常。你的通信协议有没有超时重传？你的数据存储有没有掉电保护？你的用户输入有没有合法性校验？这些问题的答案决定了你的系统是“能跑”还是“能扛”。

第二是可观测性的建设。系统出问题了，你怎么知道？靠用户打电话投诉吗？工程级的做法是：系统自己记录关键事件，提供运行状态查询接口，异常时主动上报。STM32 上可以用串口打印加 Flash 日志，Linux 上可以用 syslog 加监控脚本。没有可观测性的系统，出了问题就是黑盒，排查全靠猜。

第三是可维护性的设计。你的代码三个月后自己还看得懂吗？参数改了要不要重新烧录？固件升级要不要拆机？工程级的项目会把配置外置、把升级通道留好、把代码分层解耦。这些设计在演示阶段看不出价值，但在交付阶段就是救命稻草。

3. 核心细节解析与实操要点

3.1 状态机设计：让系统行为可预测

状态机是工程闭环里最基础也最重要的设计模式。玩具级项目通常用一堆 if-else 堆砌逻辑，工程级项目会把系统行为抽象成有限状态机。为什么？因为状态机让系统的行为可预测、可测试、可恢复。

以 STM32 上的一个通信网关为例。玩具级的写法可能是：主循环里轮询串口，收到数据就解析，解析完就转发，转发失败就重试。这种写法在正常情况下没问题，但一旦通信模块进入异常状态，整个逻辑就乱了。工程级的写法是：定义 IDLE、CONNECTING、CONNECTED、RECONNECTING、ERROR 几个状态，每个状态有明确的进入条件、退出条件和超时处理。主循环只负责驱动状态机，具体行为由当前状态决定。

typedef enum { STATE_IDLE, STATE_CONNECTING, STATE_CONNECTED, STATE_RECONNECTING, STATE_ERROR } gateway_state_t; typedef struct { gateway_state_t current_state; uint32_t state_enter_time; uint32_t retry_count; uint32_t last_rx_time; } gateway_ctx_t; void gateway_state_machine(gateway_ctx_t *ctx) { switch (ctx->current_state) { case STATE_IDLE: if (has_network_config()) { ctx->current_state = STATE_CONNECTING; ctx->state_enter_time = get_tick(); } break; case STATE_CONNECTING: if (connect_success()) { ctx->current_state = STATE_CONNECTED; ctx->retry_count = 0; } else if (get_tick() - ctx->state_enter_time > CONNECT_TIMEOUT_MS) { ctx->current_state = STATE_RECONNECTING; ctx->retry_count++; } break; case STATE_CONNECTED: if (get_tick() - ctx->last_rx_time > HEARTBEAT_TIMEOUT_MS) { ctx->current_state = STATE_RECONNECTING; } break; case STATE_RECONNECTING: if (ctx->retry_count > MAX_RETRY) { ctx->current_state = STATE_ERROR; log_error("max retry reached"); } else if (reconnect_success()) { ctx->current_state = STATE_CONNECTED; } break; case STATE_ERROR: // 等待人工干预或定时自动恢复 break; } }

这段代码的价值不在于多复杂，而在于它把“通信断了怎么办”这个问题变成了一个可讨论、可修改、可测试的设计。面试的时候你把这段逻辑讲出来，面试官就知道你是有系统思维的。

Linux 侧的状态机通常体现在进程管理上。比如一个数据采集程序，玩具级写法是 while(1) 里读传感器、写文件，出错就退出。工程级写法是：主进程负责监控，工作进程负责采集，工作进程异常退出时主进程负责重启，重启次数超过阈值就告警。这种设计用 systemd 的 Restart 策略或者自己写守护进程都能实现，核心思想是一样的：把异常恢复逻辑从业务逻辑里剥离出来。

3.2 错误处理与日志体系：出问题时你能知道

错误处理和日志是面试官判断“玩具级”还是“工程级”最直接的切入点。玩具级项目的错误处理通常是 printf 打印一句“error”然后继续跑，或者干脆不处理。工程级项目会定义错误码、分级日志、记录上下文。

先说错误码。很多开发者习惯用返回值 0 和 -1 表示成功失败，这在简单场景够用，但在复杂系统里信息量太少。工程级的做法是定义一套错误码枚举，每个错误码对应明确的含义和处理建议。

typedef enum { ERR_OK = 0, ERR_TIMEOUT = -1, ERR_CHECKSUM = -2, ERR_NO_MEMORY = -3, ERR_INVALID_PARAM = -4, ERR_HARDWARE_FAULT = -5, ERR_STORAGE_FULL = -6 } error_code_t;

配合错误码，日志也要分级。我通常分四级：ERROR 表示系统无法继续正常功能，需要立即关注；WARN 表示出现了异常但系统还能降级运行；INFO 表示关键状态变更，用于追踪流程；DEBUG 表示详细调试信息，量产版本可以关闭。STM32 上可以用宏定义控制日志级别，Linux 上可以用 syslog 的 LOG_ERR、LOG_WARNING 等。

#define LOG_LEVEL_ERROR 1 #define LOG_LEVEL_WARN 2 #define LOG_LEVEL_INFO 3 #define LOG_LEVEL_DEBUG 4 #ifndef CURRENT_LOG_LEVEL #define CURRENT_LOG_LEVEL LOG_LEVEL_INFO #endif #define LOG_ERROR(fmt, ...) \ do { if (CURRENT_LOG_LEVEL >= LOG_LEVEL_ERROR) \ log_output("ERROR", __FILE__, __LINE__, fmt, ##__VA_ARGS__); } while(0)

这里有个实操心得：日志里一定要带时间戳和模块名。我见过太多项目日志只有一句“failed”，排查的时候完全不知道是哪个模块、什么时候出的问题。STM32 上可以用 RTC 提供时间戳，没有 RTC 就用 tick 计数；Linux 上直接用 syslog 自带的时间戳。模块名可以用宏在编译时自动填入，省得手写。

还有一个容易被忽略的点：日志的存储和轮转。STM32 上如果往 Flash 写日志，要考虑擦写寿命和存储空间，通常用环形缓冲区覆盖最旧的数据。Linux 上如果往文件写日志，要配置 logrotate 防止磁盘写满。这些细节面试官一问就能试出你有没有实际交付过项目。

3.3 参数管理与固件升级：交付后的生命线

参数管理和固件升级是很多开发者完全没考虑过的环节，但恰恰是工程闭环里最能体现“交付思维”的部分。玩具级项目的参数通常硬编码在代码里，改一个阈值要重新编译烧录。工程级项目会把参数外置到 Flash 或配置文件，支持运行时修改和掉电保存。

STM32 上的参数管理通常用内部 Flash 的最后一页或者外部 EEPROM。关键设计点有三个：一是掉电保护，写参数时先擦除备份区、写入新值、校验通过后再更新主区，防止写一半掉电导致参数损坏；二是磨损均衡，如果频繁写参数，要用多个扇区轮换写，避免单个扇区提前失效；三是默认值恢复，参数区校验失败时自动加载默认值，保证系统能启动。

typedef struct { uint32_t magic; uint32_t version; uint32_t baudrate; uint32_t report_interval; uint16_t crc; } device_config_t; bool config_save(const device_config_t *cfg) { device_config_t temp = *cfg; temp.magic = CONFIG_MAGIC; temp.crc = crc16((uint8_t*)&temp, sizeof(temp) - sizeof(uint16_t)); // 先写备份区 if (!flash_write(CONFIG_BACKUP_ADDR, &temp, sizeof(temp))) { return false; } // 校验备份区 if (!config_verify(CONFIG_BACKUP_ADDR)) { return false; } // 再写主区 if (!flash_write(CONFIG_MAIN_ADDR, &temp, sizeof(temp))) { return false; } return config_verify(CONFIG_MAIN_ADDR); }

Linux 侧的参数管理相对简单，通常用配置文件加原子写。所谓原子写就是先写临时文件，fsync 落盘后再 rename 覆盖原文件，这样即使写的过程中断电，原配置文件也不会损坏。这个技巧在面试里提一句，面试官就知道你踩过坑。

固件升级方面，STM32 通常需要 Bootloader 加双区备份。Bootloader 负责接收新固件、校验 CRC、写入备份区、切换启动标志。应用区负责正常运行，收到升级命令后跳转到 Bootloader。关键点是升级过程中掉电不能变砖，所以要有回滚机制：新固件启动失败时自动切回旧固件。Linux 侧的升级可以用包管理或者容器镜像，核心思路也是版本管理和回滚能力。

3.4 资源约束下的取舍：堆栈、内存与实时性

STM32 项目绕不开资源约束，这也是面试官区分新手和老手的重要维度。新手写代码不太关心堆栈用了多少、中断关了多久、内存有没有碎片。老手会主动计算和监控这些指标。

堆栈估算是个典型例子。裸机程序里，主栈大小通常在启动文件里定义，很多人直接抄默认值，从不修改。工程级的做法是：分析最深的中断嵌套和函数调用链，估算最坏情况下的栈使用量，然后留 30% 余量。更稳妥的做法是在栈顶和栈底放魔术字，运行一段时间后检查魔术字有没有被覆盖，从而实测栈水位。

#define STACK_MAGIC 0xDEADBEEF extern uint32_t _estack; extern uint32_t _sstack; void stack_watermark_check(void) { uint32_t *stack_start = &_sstack; uint32_t *stack_end = &_estack; uint32_t used = 0; for (uint32_t *p = stack_start; p < stack_end; p++) { if (*p != STACK_MAGIC) { used = (uint32_t)(stack_end - p) * 4; break; } } log_info("stack used: %u bytes", used); }

内存管理方面，裸机项目通常禁用 malloc，改用静态分配或内存池。原因是 malloc 在长期运行的系统里容易产生碎片，最终导致分配失败。内存池的做法是预先分配固定大小的块，用链表管理空闲块，分配和释放都是 O(1) 操作，没有碎片问题。这个设计在通信协议解析、数据缓存场景里特别常用。

实时性方面，中断服务函数要尽可能短。我见过有人在中断里做浮点运算、调用 printf、甚至写 Flash，这些都是大忌。工程级的做法是：中断里只做标志位设置和数据搬运，复杂处理放到主循环或任务里。如果必须用 RTOS，要合理分配任务优先级，避免优先级反转和死锁。

4. 完整实操流程与核心环节实现

4.1 从零搭建一个带闭环的 STM32 数据采集节点

我以一个实际做过的数据采集节点为例，把工程闭环的搭建过程完整走一遍。需求是：采集四路模拟量，通过串口上报，支持参数远程配置，异常时能记录并恢复。这个需求看起来简单，但把闭环补全后，代码量和设计复杂度会翻好几倍。

第一步是硬件抽象层设计。不要直接在业务代码里调 HAL 库，而是封装一层 bsp 接口。这样做的好处是业务逻辑不依赖具体芯片，换平台时只改 bsp 层。bsp 层提供 adc_read、uart_send、flash_write、wdt_feed 这些统一接口，业务层只调这些接口。

// bsp.h typedef struct { int (*adc_init)(void); int (*adc_read)(uint8_t ch, uint16_t *value); int (*uart_init)(uint32_t baudrate); int (*uart_send)(const uint8_t *data, uint16_t len); int (*flash_read)(uint32_t addr, void *buf, uint32_t len); int (*flash_write)(uint32_t addr, const void *buf, uint32_t len); void (*wdt_feed)(void); } bsp_ops_t; extern const bsp_ops_t bsp;

第二步是状态机与任务调度。主循环里不写具体业务，而是驱动几个任务：采集任务、通信任务、参数管理任务、看门狗任务。每个任务有独立的计时器和状态。这种结构在裸机上可以用时间片轮询实现，在 RTOS 上就是独立线程。

void main_loop(void) { uint32_t now = get_tick(); if (now - last_sample_tick >= sample_interval) { sample_task(); last_sample_tick = now; } if (now - last_comm_tick >= comm_interval) { comm_task(); last_comm_tick = now; } if (now - last_param_tick >= param_check_interval) { param_task(); last_param_tick = now; } wdt_feed(); }

第三步是异常处理与恢复。每个任务内部都要处理自己的异常。采集任务如果读到异常值，要记录并标记数据无效；通信任务如果发送失败，要缓存数据并重试；参数任务如果校验失败，要加载默认值并记录事件。这些处理逻辑要写成独立的函数，方便单元测试。

第四步是日志与可观测性。定义一个环形缓冲区作为日志存储，ERROR 级别日志同时输出到串口和 Flash，WARN 和 INFO 只输出串口。提供一个查询接口，可以通过串口命令读取最近的日志记录。这个设计在排查现场问题时特别有用。

第五步是参数与升级。参数区放在 Flash 最后一页，升级功能通过 Bootloader 实现。Bootloader 和应用的通信协议要简单可靠，通常用 YMODEM 或者自定义的帧协议。升级前要校验固件完整性，升级后要能回滚。

这套流程走下来，代码量大概是玩具级项目的三到五倍，但换来的是可维护、可排查、可交付的系统。面试的时候你把这五步讲清楚，再配合实际代码片段，面试官对你的评价会完全不一样。

4.2 Linux 侧守护进程与日志系统的落地

Linux 侧我以一个数据上报服务为例。需求是：周期性读取传感器数据，上报到远端，支持配置热加载，异常时自动重启并记录日志。玩具级的写法是一个 while(1) 循环加 printf，工程级的写法是守护进程加 syslog 加信号处理。

第一步是守护进程化。用 fork 加 setsid 让进程脱离终端，重定向标准输入输出到 /dev/null，防止终端关闭导致进程退出。更现代的做法是用 systemd 管理，写一个 service 文件，配置 Restart=always 和 RestartSec=5，让 systemd 负责进程监控和重启。

[Unit] Description=Data Reporter Service After=network.target [Service] Type=simple ExecStart=/usr/bin/data_reporter -c /etc/data_reporter.conf Restart=always RestartSec=5 StandardOutput=syslog StandardError=syslog SyslogIdentifier=data_reporter [Install] WantedBy=multi-user.target

第二步是信号处理。守护进程要响应 SIGTERM 做优雅退出，响应 SIGHUP 做配置重载。信号处理函数里不能做复杂操作，通常只设置一个标志位，主循环检测到标志位后再执行具体逻辑。

static volatile sig_atomic_t g_reload_flag = 0; static volatile sig_atomic_t g_exit_flag = 0; void signal_handler(int sig) { if (sig == SIGHUP) g_reload_flag = 1; if (sig == SIGTERM) g_exit_flag = 1; } int main(void) { signal(SIGHUP, signal_handler); signal(SIGTERM, signal_handler); while (!g_exit_flag) { if (g_reload_flag) { reload_config(); g_reload_flag = 0; } do_work(); } cleanup(); return 0; }

第三步是日志分级与轮转。用 syslog 的 LOG_ERR、LOG_WARNING、LOG_INFO、LOG_DEBUG 分级，配合 rsyslog 的配置把不同级别写到不同文件。日志轮转用 logrotate，配置按大小或按天切割，保留最近 N 份。这样既不会写满磁盘，又能保留足够的历史记录。

第四步是资源监控与自愈。守护进程要监控自己的文件描述符数量、内存使用量、线程数量，超过阈值时记录告警。如果依赖的外部服务不可用，要有退避重连策略，避免频繁重试打爆对方。这些逻辑用简单的计数器加定时器就能实现，不需要引入复杂的监控框架。

4.3 关键参数的计算与选择过程

工程闭环里有很多参数需要计算和选择，面试官经常通过这些问题考察你的基本功。我挑几个典型的讲一下计算过程。

看门狗超时时间怎么定？原则是：大于系统最坏情况下的主循环执行时间，小于用户能接受的最大无响应时间。假设你的主循环最慢路径是 200ms，用户能接受 2 秒无响应，那看门狗超时可以定在 500ms 到 1 秒之间。定太短会误复位，定太长失去保护意义。喂狗点要放在主循环里，不能放在中断里，否则主循环卡死中断还在喂狗，看门狗就失效了。

通信超时和重试次数怎么定？超时时间要大于对方的最快响应时间加上网络往返延迟。比如对方处理需要 50ms，网络往返 100ms，那超时至少 200ms。重试次数要考虑总耗时，3 次重试加退避，总时间不能超过上层业务的容忍度。退避策略通常用指数退避，第一次等 1 秒，第二次 2 秒，第三次 4 秒，避免雪崩。

Flash 擦写寿命怎么估算？假设 Flash 擦写寿命 1 万次，你每天写 100 次参数，那单个扇区能用 100 天。如果产品要求用 5 年，就需要至少 18 个扇区轮换。这个计算在选型阶段就要做，不能等产品上市了才发现 Flash 写坏了。

堆栈大小怎么估算？最笨但最可靠的方法是实测：把栈填满魔术字，跑完所有功能路径，看最深用到哪里。估算的话，每个函数调用按 32 到 64 字节算，中断嵌套按最坏情况算，再留 30% 余量。RTOS 里每个任务独立栈，要分别估算。

这些计算过程面试官不一定全问，但你能主动说出来，就说明你有工程思维，不是只会调库的“玩具级”开发者。

5. 常见问题与排查技巧实录

5.1 面试高频追问与应对思路

我把这些年面试别人和被面试时遇到的高频追问整理成了一张表，你可以对照自己的项目提前准备答案：

这张表里的工程级回答不是让你背下来，而是提醒你：每个问题背后都对应一个设计决策，你要在自己的项目里真正做过这些设计，才能答得自然。临时编答案面试官几个追问就露馅了。

5.2 实际调试中踩过的坑与解决记录

坑一：看门狗喂狗点放错位置。早期项目我把喂狗放在定时器中断里，结果主循环卡死在某个 while 循环里，中断还在正常喂狗，看门狗完全没起作用。后来改成主循环喂狗，并且加了一个主循环计数器，每个任务执行后递增，喂狗前检查计数器有没有变化，没变化就主动复位。这个技巧叫“窗口看门狗”的软件实现，能检测到任务卡死。

坑二：Flash 写参数时掉电导致配置丢失。有次现场设备断电后起不来，排查发现是参数区写了一半掉电，CRC 校验失败，系统加载默认值后网络配置丢了。后来改成双区备份加原子切换，写新参数时先写备份区，校验通过后再更新主区，启动时如果主区校验失败就尝试备份区。这个改动之后再也没有出现过配置丢失。

坑三：Linux 守护进程日志把磁盘写满。有个数据上报服务跑了一个月，磁盘满了导致系统异常。排查发现日志没有轮转，DEBUG 级别日志一直往文件里写。后来配置了 logrotate 按天切割保留 7 天，并且把量产版本的日志级别调到 INFO，问题解决。这个教训是：日志一定要有上限，不管是大小上限还是时间上限。

坑四：串口通信没有帧边界导致解析错乱。早期协议设计只定义了帧头和帧尾，没有长度字段，遇到数据里恰好出现帧尾字节就解析错误。后来改成帧头加长度加载荷加 CRC 的格式，解析时先找帧头，再读长度，再校验 CRC，稳定了很多。这个坑在自定义协议设计里非常常见，面试官也爱问。

坑五：RTOS 任务优先级设置不当导致低优先级任务饿死。有个项目里高优先级任务频繁唤醒，低优先级任务一直得不到执行，看门狗喂狗任务被饿死导致复位。后来调整了优先级，并且在高优先级任务里加了延时让出 CPU。RTOS 里优先级反转和任务饿死是经典问题，面试官问起来你要能说清楚。

5.3 独家避坑清单与经验总结

最后分享一份我自己整理的避坑清单，都是实际交付中总结出来的，常规文档里不会写：

• 中断里不要调用可能阻塞的函数，包括 printf、malloc、Flash 写操作。这些函数执行时间不确定，会破坏实时性。
• 所有外设初始化后要检查返回值，不要假设初始化一定成功。我见过 I2C 初始化失败但代码继续跑，后面读传感器全是 0 的情况。
• 通信协议一定要有 CRC 或校验和，不要依赖物理层的可靠性。电磁干扰、线缆接触不良都会导致数据错误。
• 参数区要留版本号，方便后续升级时做参数迁移。没有版本号的话，新固件读旧参数可能解析错误。
• 日志里不要打印敏感信息，比如密钥、密码、用户隐私数据。量产版本要关闭 DEBUG 日志。
• 看门狗复位后要记录复位原因，STM32 可以用 RCC 的复位标志寄存器，Linux 可以看内核日志。知道为什么复位是排查问题的第一步。
• 升级前一定要备份当前固件，升级失败时能回滚。没有回滚机制的升级就是赌博。
• 测试要覆盖异常路径，正常路径谁都能跑通，异常路径才见功力。拔电源、拔网线、发错误数据，这些测试做完你对自己的系统才有信心。

这些经验看起来琐碎，但每一条背后都是真金白银的教训。面试的时候你随口提一两条，面试官就知道你是真正交付过项目的人，而不是只做过课程设计的“玩具级”开发者。

我个人在实际带团队和面试的过程中发现，技术深度可以慢慢积累，但工程思维的有无是分水岭。一个具备工程闭环思维的开发者，哪怕当前只会 STM32，给他一块 Linux 板子他也能快速上手，因为他知道该关注什么、该设计什么。反过来，一个只会调库实现功能的开发者，换一个平台就从头开始，永远在“玩具级”打转。把上面这些闭环环节对照自己的项目补起来，下次面试再被问到“通信断了怎么办”，你就能给出让面试官眼前一亮的答案。