模块化代码在嵌入式开发中不是一种可选的编程风格，而是一种工程生存策略。我在实际项目中经历过三次因代码耦合导致的紧急返工：一次是客户要求将原本基于USART1的AT指令模块迁移到USART3，结果发现串口初始化、中断处理、缓冲区管理、超时重试逻辑全部散落在main.c的27个函数里，改了三天仍无法通过Modem注册测试；第二次是把一个运行在STM32F103上的温控PID算法移植到ESP32上，由于ADC采样、定时器触发、控制输出完全硬编码在单个while循环中，不得不重写60%的逻辑；第三次最典型——某工业网关固件升级后，Wi-Fi连接失败率从0.3%飙升至12%，最终定位到是因为看门狗喂狗位置被挪到了一个新增的LED闪烁任务里，而该任务在特定信号强度下会因FreeRTOS调度延迟超过WDT timeout。这三件事共同指向一个事实：嵌入式系统的维护成本，80%以上不来自功能实现，而来自修改、移植和调试过程中暴露的隐式依赖。1. 模块化的本质：解耦时间、空间与职责模块化常被误解为“把代码按功能切开”，但真正的模块化是围绕三个不可回避的物理约束展开的：时间约束（实时性）、空间约束（内存/Flash）、职责约束（谁该对什么负责）。这三个维度决定了模块边界不能由开发者主观划分，而必须由硬件行为和系统架构客观定义。1.1 时间维度：中断、主循环与任务的天然分层嵌入式系统的时间模型是分层的。以STM32为例，中断服务程序（ISR）必须在微秒级完成，因此其职责只能是“捕获事件”——比如USART接收中断只做一件事：将接收到的字节存入环形缓冲区，并置位接收完成标志。它绝不能执行协议解析、数据校验或调用printf。这些操作必须移交到主循环或任务