接第一个外部设备的那天，我的驱动层只有两百来行，一个类管到底，读起来清爽得像刚擦过的玻璃。三个月后，同一个文件涨到两千多行，里面塞着四种不同型号的执行器、两套通信协议、一堆 if-else 分支，以及我自己都记不清什么时候加进去的临时补丁。改一处逻辑，另外两个型号的行为就跟着变；加一个新设备，得先把老代码通读一遍才敢动手。那段时间我最怕的不是写代码，是"确认这次改动没有把别的设备弄坏"。

这就是 LeGo-Drive 出现的直接原因。LeGo 取的是"拼装"的意思——把驱动层拆成一块块边界清晰、能单独测试、能随手替换的零件；Drive 指的就是这一层本身：设备接入、能力封装、时序调度、状态回传。它不是一个具体的库，也不是某个平台的 SDK，而是一套组织驱动代码的结构约定和最小运行时。目标很朴素：接第五种设备的时候，我不想再改前四种设备的任何一行代码。这套东西适合谁？写过设备驱动、做过运动控制、维护过"祖传"硬件接入层的人应该最有共鸣；如果你正在为一个多型号、多协议、需要长期迭代的项目写底层，那这篇里的结构约定和踩坑记录大概率能省你几周时间。

1. 把驱动层拆成能拼的零件，动机是什么

1.1 一次设备接入引发的连锁返工

先说清楚问题是怎么暴露的。项目早期只有一种执行器，通信走的是串口，代码写得很直白：打开端口、发指令、读回包、解析、更新状态，全在一个类里。第二种执行器进来时，通信换成了另一种总线，我加了个分支，把发送和解析两处按型号分开，勉强能看。真正的转折点是第三种设备——它的控制周期比前两种短一个数量级，而且支持中途打断。

当时我做的第一件事是加判断：如果型号是 C，就走快速路径，否则走原来的慢路径。代码跑起来了，但紧接着出现三个连锁反应。第一，状态回传的时间戳被统一成了"主循环的时间"，导致 C 设备的实际响应延迟在日志里完全看不出来。第二，紧急停止逻辑原本写在慢路径里，C 设备走快速路径时绕过了它，测试时差点把限位撞穿。第三，也是最要命的，我在修上面两个问题的时候，顺手改了一个公共的解析函数，结果第一种设备的返回值全错了一位。

这三件事的共同点不是"我水平不行"，而是结构上没有隔离。所有设备共享同一份状态、同一套时间基准、同一个解析入口，任何一处改动的影响面都是全局的。返工三周之后我意识到，与其继续在旧结构上打补丁，不如先把"什么东西应该被隔离"这件事想清楚。

1.2 三种常见写法，各自在哪一步崩掉

我把接触过的驱动层写法归了三类，每一类在项目规模小的时候都没问题，问题都出在扩展阶段。列个表对照一下，方便你判断自己现在处在哪一格。

单体类的崩塌是必然的，因为它把"变化的部分"和"不变的部分"揉在一起。继承式的问题更隐蔽：一开始看起来扩展性很好，新增设备只要写个子类，但一旦遇到需要跨设备统一处理的东西——比如所有设备都必须支持的三级急停、所有指令都要记审计日志——继承体系就没办法优雅地表达，最后只能往基类里堆代码，基类慢慢变成一个什么都干的怪物。事件回调式最坑的地方在于调试：一个回调触发了另一个回调，第二个又改了共享状态，等到出问题的时候，日志里只剩一堆没有因果关系的打印。

判断标准很简单：如果你加一个新设备，需要修改的文件数量超过两个，说明结构已经开始漏了。

1.3 LeGo-Drive 把哪些东西拆开了

拆分的思路不是按"设备型号"分，而是按"职责变化的原因"分。同一类职责，如果它的变化原因和别的职责不同，就应该被拆开。按这个原则，我把驱动层切成三层、两条通道。

三层是：适配层负责和具体硬件说话，只管收发字节、解析成结构化数据，不知道上层拿这些数据干什么；能力层把结构化数据封装成有语义的操作，比如"移动到某位置""查询当前负载"，同一个能力可以由不同适配器实现；编排层决定什么时候调用哪个能力、多个动作之间怎么排序、冲突怎么仲裁。

两条通道是：控制通道自上而下传递意图，状态通道自下而上回传事实。这两条通道必须在代码层面分离，不能在同一个对象里互相读写。这一点听起来像废话，但它是后面所有时序问题、状态错乱问题的根源——只要控制和状态共享同一个可变对象，你就永远说不清某一时刻读到的是"指令"还是"事实"。

拆完之后再看新增设备这件事：绝大多数情况下只需要写一个新的适配器，能力层和编排层零改动。如果新设备有编排层没见过的新能力，那就在能力层加一个语义定义，其他适配器不实现就用默认的空实现兜底。真正需要改编排层的场景，基本只有"动作的先后顺序发生本质变化"，这种改动频次天然就低。

2. 模块契约怎么定，才不至于三个月后重来

2.1 五个必选角色与它们的最小职责

拆完层之后，我遇到的第一个具体问题是：模块之间的接口到底该长什么样。接口定宽了，模块之间耦合依旧；定窄了，稍微变点需求就得改契约，改契约等于全量回归。反复调了几轮之后，我固定在五个角色上，每个角色的职责窄到只用一句话能说完。

这张表最有用的一列是"明确禁止"。工程上，"这个模块该干什么"往往靠文档说不清楚，但"这个模块绝对不能干什么"是可以靠代码审查卡死的。比如一旦规定 Scheduler 不许直接调 Adapter，时序问题就不可能出现在适配层，排查范围直接缩小一半。

Arbiter 这个角色容易被忽略。刚开始我觉得冲突处理是小事，直接在上层写几个 if 就完了，后来发现冲突处理会随着设备数量指数级增长：两个动作同时要求不同目标位置怎么办？一个动作正在执行时来了急停怎么办？急停之后原来的动作算完成还是算中断？这些判断集中在一个地方，逻辑就只是一段状态机；散在各处，就是永远修不完的边界情况。

2.2 生命周期钩子怎么排，以及为什么是这个顺序

五个角色确定之后，下一个坑是模块的启动和关闭顺序。我最初的实现是"谁先注册谁先启动"，看着挺合理，实际跑起来经常出现 Scheduler 已经开始发指令、Adapter 的通信端口还没打开的情况，指令直接被吞掉，日志里干干净净什么都没有。

后来固定成六个钩子，并且强制按顺序执行：init→bind→start→tick→stop→release。

init只做参数解析和内部字段初始化，不碰任何外部资源；bind建立依赖关系，比如把 Adapter 实例注入到 Capability 里，这一步只做引用绑定不做实际通信；start才真正打开端口、启动后台线程；tick是周期执行入口，可以反复调用；stop负责停止后台线程并等待其退出；release释放资源。启动严格按依赖顺序正序执行，关闭严格逆序执行。

这个顺序的价值在于，任何一步失败都能明确知道"前面哪些步骤已经完成、需要回滚哪些"。我在start里踩过一次坑：某个设备打开端口成功但握手超时，抛出异常时端口没有关闭，下次启动直接报"端口被占用"。后来规定start内部必须自己保证失败时释放自己申请的资源，异常才能往上抛。这条约定写进契约之后，同类问题再没出现过。

2.3 契约里最容易埋雷的三类字段

接口签名一般不会出大错，真正埋雷的是字段的语义。有三类字段我在不同项目里反复被坑。

第一类是物理单位。同一个字段，有的设备返回毫米，有的返回米，有的返回脉冲数。我见过最离谱的是同一家厂商的两个型号，说明书上都写"单位：个"，实际一个是整步数一个是微步数。解决办法很笨但有效：所有跨模块传递的数值字段，名字里必须带单位后缀，比如position_mm、velocity_mmps、torque_nm，单位换算只允许发生在 Adapter 内部。

第二类是时间基准。是本地单调时钟还是墙钟？是采样时刻还是接收时刻？这个字段错了，所有延迟分析和时序对齐全废。我的做法是统一用单调时钟，并且在状态结构里同时保留sample_ts和recv_ts两个字段，虽然冗余，但排查问题时能立刻区分"设备慢"和"链路慢"。

第三类是索引基准。轴号从 0 开始还是从 1 开始，坐标系是右手还是左手，角度是弧度还是度。这类错误不会报异常，只会让结果悄悄偏掉。我曾经因为一个轴号基准的差异，排查了整整两天——现象是"动作执行了但位置不对"，中间怀疑过编码器、怀疑过减速比，最后发现是配置文件里写的是 1 起始、代码里按 0 起始解析。

这三类字段的共同特点是"错了不报错"。凡是属于这一类的字段，都值得在名字上做冗余标注，宁可名字长一点。

3. 拼出第一个能跑的最小组合

3.1 目录骨架与配置文件的组织方式

光说结构容易飘，直接看我实际用的目录骨架。这个骨架用过四五个项目，基本没大改过。

legodrive/ ├── adapters/ # 每个物理设备一个文件 │ ├── serial_actuator.py │ └── can_actuator.py ├── capabilities/ # 按语义划分，不按设备划分 │ ├── position.py │ └── homing.py ├── runtime/ │ ├── scheduler.py │ ├── arbiter.py │ └── telemetry.py ├── contracts/ # 数据结构与接口定义，全项目唯一真源 │ ├── state.py │ └── interfaces.py └── configs/ └── single_axis.yaml

关键是contracts/这个目录。所有跨模块传递的数据结构、所有接口的抽象定义，都放这里，别的地方不许重复定义。这样做的好处是，看接口只需要看一个文件，改接口的影响面也能静态扫出来。adapters按设备分文件，capabilities按语义分文件——这个区分很重要，一种能力可能对应多个适配器，一个适配器也可能支撑多种能力。

配置文件我坚持用 YAML 而不是代码里硬编码，原因是不同现场的硬件组合差异很大，改配置不需要重新走一遍构建流程。

runtime: tick_hz: 200 clock: monotonic modules: actuator_main: type: serial_actuator params: port: /dev/ttyS1 baud: 921600 unit_scale: 0.001 # 脉冲 -> mm position: type: position params: adapter: actuator_main max_velocity_mmps: 120 soft_limit_mm: [-5.0, 245.0] telemetry: fields: [position_mm, velocity_mmps, current_a, sample_ts] ring_size: 8192

unit_scale这个参数是我强烈建议保留的。它把单位换算从代码挪到了配置，换型号的时候改一个数就行，不用碰代码。tick_hz也要显式写出来，不要用默认值，因为不同组合对周期的要求差别很大，写出来才能被审查。

3.2 一个最小适配器的完整实现

适配器要写的代码其实很少，因为它的职责被压得很窄。下面这个骨架是串口执行器的，去掉业务细节之后大概是这样。

import struct from contracts.state import ActuatorState from contracts.interfaces import Adapter class SerialActuator(Adapter): def __init__(self, params): self.port = params["port"] self.baud = params["baud"] self.scale = params.get("unit_scale", 1.0) self._link = None self._seq = 0 def init(self, ctx): self._ctx = ctx def start(self): try: self._link = open_link(self.port, self.baud) self._handshake() except Exception: self._close_quietly() raise def _close_quietly(self): if self._link is not None: try: self._link.close() except Exception: pass self._link = None def read_state(self): raw = self._link.read_frame(timeout_ms=2) if raw is None: return None pos_pulse, vel_pulse, cur_raw, dev_tick = struct.unpack("<iiiI", raw) return ActuatorState( position_mm=pos_pulse * self.scale, velocity_mmps=vel_pulse * self.scale, current_a=cur_raw / 1000.0, sample_ts=self._ctx.clock.now(), recv_ts=self._ctx.clock.now(), ) def write_command(self, target_mm, velocity_mmps): self._seq = (self._seq + 1) & 0xFFFF pulse = round(target_mm / self.scale) frame = struct.pack("<BHiI", 0xA5, self._seq, pulse, int(velocity_mmps / self.scale)) self._link.write(frame, timeout_ms=2) def stop(self): self._close_quietly()

几个细节值得单独说。read_state返回None表示"这一周期没读到新帧"，而不是返回上一帧的旧数据——这个约定非常重要，如果返回旧数据，上层根本无法区分"设备没动"和"设备没回"。start里的try/except保证了握手失败时端口一定被关闭，就是我前面提到的那个坑。序列号_seq是给适配器自己做丢帧检测用的，上层不需要知道。

scale的除法方向也要注意：配置里写的是"一个脉冲等于多少毫米"，那么脉冲转毫米是乘，毫米转脉冲是除，反过来写会导致速度指令差一千倍，而且不会报错，只会让设备跑得莫名其妙。

3.3 编排层怎么写：把适配器和能力接起来

能力层通常是薄薄一层，主要做参数校验和语义转换。真正的"拼装"发生在编排层，也就是 Scheduler 和 Arbiter 这一层。

def build(config, clock): modules = {} for name, spec in config["modules"].items(): cls = REGISTRY[spec["type"]] modules[name] = cls(spec.get("params", {})) for name, spec in config["modules"].items(): modules[name].init(SimpleNamespace(clock=clock, modules=modules)) # 按依赖拓扑排序后正序启动 for name in topo_sort(config["modules"]): modules[name].start() return modules def run_tick(modules, arbiter, scheduler, telemetry): for name, mod in modules.items(): state = mod.read_state() if hasattr(mod, "read_state") else None if state is not None: telemetry.push(name, state) intent = scheduler.next_intent() final = arbiter.resolve(intent) if final is not None: modules[final.capability].execute(final)

这段代码里有三个设计选择，都值得解释一下。第一，读取状态和下发指令分成两个独立循环，读取循环遍历所有模块，下发循环只处理仲裁后的唯一意图。这样即使某个设备读取超时，也不会阻塞指令下发。第二，arbiter.resolve返回None表示"本周期不下发"，这是处理急停和冲突最干净的方式——不是发一个"空指令"，而是根本不发。第三，拓扑排序启动而不是按配置顺序启动，因为配置文件里的顺序是给人看的，不应该承担依赖语义。

3.4 跑通之后必须做的三组自检

代码能跑不等于能上线。我固定做三组自检，每次新增设备或改动契约后都重跑一遍。

第一组是空载阶跃。给一个目标位置，记录从下发到位置进入误差带的时间。重点不是看这个时间有多短，而是看多次重复的离散程度。如果同一指令的响应时间抖动很大，说明时序上有不确定因素，多半是调度周期和设备自身周期没有对齐。

第二组是限位与急停。故意让目标位置超出软限位，确认被拦截且状态通道里有明确的拒绝原因；在执行过程中触发急停，确认动作确实中断、并且中断后的状态是"已停止"而不是"执行中"。这组测试最容易暴露 Arbiter 的状态机漏洞。

第三组是断连恢复。在运行中拔掉通信线，观察是否能在合理时间内检测到、是否会自动尝试重连、重连后状态是否会出现跳变。这一步能验证适配器的资源释放逻辑，也能验证上层对"数据中断"的处理。

这三组自检加起来不到半小时，但能覆盖我遇到过的八成低级问题。建议直接脚本化，别靠手动。

4. 时序：拼装结构要付的真实代价

4.1 每一层拼装，延迟是怎么叠上去的

拆模块不是免费的。每加一层抽象，就多一次数据拷贝、多一次函数调用、多一次格式转换。单看每次开销都是微秒级，但在高周期场景下会累积成可观测的问题。

我做过一次粗略测量，在同一个硬件平台上，从"上层发起意图"到"字节真正出现在总线上"的时间消耗大致是：编排层决策约 30 微秒，能力层参数校验与转换约 15 微秒，适配层编码与写缓冲约 40 微秒，加上调度等待平均一半周期，200Hz 下就是 2.5 毫秒左右。如果直接把这三层揉在一起写，总开销大概能压到 50 微秒以内。

也就是说，为了结构清晰，我付出了大约 35 微秒的额外开销和一层抽象的理解成本。这个代价在大部分场景下完全值得，但有一个例外：当控制周期低于 1 毫秒时，这几十微秒就开始变得不可忽略，甚至会和设备自身的通信周期产生拍频。这时候我的做法是给关键路径开一条直连通道，绕过部分编排逻辑，但保持契约不变——也就是说，结构上还是分层的，只是编排层对这类路径生成更短的分发代码。

这个取舍没有标准答案，但有判断依据：先量出你的周期预算，再看开销占比。占比低于 5% 就别优化了，占比超过 20% 才值得为它牺牲结构。

4.2 三种调度策略的实测对比

调度策略这件事，我前后试过三种，各有明确的适用边界。

第二种是我默认选的。它的问题——拍频——具体表现是：当设备自身刷新率是 300Hz、调度周期是 200Hz 时，某些周期内会读到两帧新数据，某些周期读不到，表现为位置曲线出现规律性的小台阶。这个问题不是靠调周期就能彻底解决的，因为设备刷新率本身也有温漂。

第三种策略解决拍频的方式是把"什么时候处理"和"数据什么时候到"绑在一起，用sample_ts做对齐，而不是靠周期去卡。代价是调试变难：事件驱动的代码在日志里是乱序的，你必须靠时间戳重建因果。

4.3 用统一时间基准替代"看起来对"的轮询

我最开始用轮询的时候，判断"数据是不是新的"靠的是一个布尔标记，适配器读到新帧就置位，处理完清掉。这套逻辑在小规模下没问题，一旦设备变多就开始出错，因为置位和清位发生在不同模块里，中间任何一个环节异常都会让标记卡住。

后来统一改成时间戳比较：每个模块记录自己最后一次处理的sample_ts，只有新数据的sample_ts严格大于它才处理。这个改动看起来只是换了个判断条件，实际影响很大——它让"新不新"变成了一个无状态判断，不再依赖任何模块的中间状态。

配套的一个约定是：所有模块的时钟必须来自同一个时钟源，通过上下文注入，不允许模块自己调用时间函数。这条规定一开始让我觉得小题大做，直到有一次混用之后，日志里出现了时间戳倒流，排查了半天才发现某处用了系统时间、另一处用了单调时钟。统一时钟源之后，日志可以直接按时间排序，因果关系清清楚楚。

5. 一次间歇性丢帧的完整排查链路

5.1 现象：每四十分钟左右抖一次

这个 bug 我印象很深，因为它的复现周期太长，一上午最多抓到两次。现象是：位置曲线在某个周期突然跳变一下，幅度大概 0.3 毫米，然后立即恢复。所有模块都没有报错，通信层没有超时记录，看门狗也没触发。

第一轮假设有三个：设备内部保护动作、通信线接触不良、上层调度周期被系统负载干扰。逐个排除的过程挺费劲——设备内部保护可以通过厂商日志确认，没有触发记录；换了两根线、换了端口，现象依旧；监控系统负载，发现抖动的时刻 CPU 占用并没有明显峰值。

排除掉这三个之后，我把范围缩小到"数据在某个环节被覆盖或错位"。这个判断依据是跳变幅度非常小且立即恢复，如果是真实的设备动作，物理上不可能这么快回来。

5.2 二分定位：从编排层一路砍到适配层

定位手段是二分。先在最上层记录每一帧从状态通道拿到的原始值，发现跳变在上层就已经存在，说明问题在状态通道以下。然后在能力层记录，跳变依旧。再往下到适配器出口，跳变还在。最后在适配器解析之前打印原始字节，跳变消失——说明问题出在"解析"这一步。

到这里范围就很窄了。解析代码只有几行：从缓冲区读固定长度、解包、乘系数。我盯着看了很久，最后发现问题在一个共享的接收缓冲区上：适配器为了减少内存分配，复用了同一个bytearray对象；后台接收线程和前台解析线程都用它，但没有做完整的同步。绝大多数时候两者节奏错开，没有问题；偶尔两次调用挤在一起，解析线程读到的就是被覆盖了一半的数据。

这个 bug 为什么四十分钟才出现一次？因为它的触发条件是"接收线程刚好在解析线程读缓冲区的中途写入"，窗口只有几微秒，概率极低。这也解释了为什么最初怀疑系统负载——负载高的时候确实更容易撞上。

5.3 根因与修复，以及修复后的验证

根因是缓冲区复用缺乏生命周期约定。修复方案有两条路：一是加锁，二是改成每次读取分配新对象。我选了后者，理由是这个路径上的数据量很小（每帧几十字节），分配开销可以忽略，而锁会引入新的不确定性——尤其在这种微秒级窗口的竞争上，锁的公平性依赖实现细节。

def read_state(self): raw = self._link.read_frame_into_new_buffer(timeout_ms=2) if raw is None: return None # 此后的 raw 只属于当前调用栈，不再共享 return decode(raw)

修复之后的验证方式是：把压力调高，人为让后台线程以两倍频率灌数据，同时前台以正常周期解析，跑了两小时没有出现跳变。另外加了一条运行时断言——解析前后的缓冲区长度必须严格等于帧长，不等就立即抛异常。这条断言后来还帮我抓到过一个协议版本不一致的问题，属于意外收获。

5.4 这类问题可以复用的排查清单

从这次之后，我整理了一份"间歇性异常"的排查顺序，遇到类似现象就按这个走。

第一，先确认异常发生在哪一层。方法是在每一层的边界处打点，比较相邻两层的输出差异，差异出现的那一层就是问题层。这一步不要靠猜，靠打点。

第二，确认问题层里有没有共享状态。共享的可变对象是间歇性问题的头号来源，包括缓冲区、缓存、连接池、单例里的字段。有共享就问三个问题：谁写、谁读、有没有生命周期约定。

第三，确认触发条件是否与时间或负载相关。如果现象有周期性，去看是不是多个周期之间产生了整除或近似整除的关系；如果和负载相关，去看竞争窗口。

第四，修复后必须构造压力条件复现。不构造压力条件就宣布修好，等于没修。我给自己定的标准是：在压力条件下跑至少两小时无复现，才算过。

这份清单最大的价值是第一条：先分层再打点。很多时候我们习惯直接跳到自己最熟悉的那一层去找，结果在最不可能的地方花掉大半天。

6. 从单轴到多机，拼装结构的扩展边界

6.1 新增一类设备时，哪些文件应该零改动

判断结构好不好，有个很直接的指标：新增一类设备时，有哪些文件必须改，有哪些文件绝对不能改。我在 LeGo-Drive 里给自己定了个硬指标——新增设备时，capabilities/和runtime/目录下的文件改动数为零。

这个指标听起来很苛刻，但实际执行下来是可行的，因为新增设备带来的差异几乎都集中在两处：编解码格式和通信方式，这两者都属于适配层的职责。只有当新设备引入了编排层从未见过的能力语义时，才需要动能力层；只有当动作之间的仲裁规则发生变化时，才需要动运行时。

为了守住这个指标，我做了一件事：给能力层的每个能力定义了一个可选的"能力声明"，适配器可以声明自己支持哪些能力的哪些子集。不支持的部分用默认实现兜底，默认实现要么是明确的空操作，要么是抛出"不支持"异常。这样编排层可以统一按能力名去调用，不需要关心背后是哪个设备。

实际跑下来，最近三次新增设备，能力层改动次数是零，运行时改动两次。两次都是因为新的仲裁场景——一次是双轴联动时两个动作争抢同一个物理资源，一次是某类设备不支持中途打断导致急停语义需要降级。这两次改动虽然违反了"零改动"目标，但都是真正的语义变化，属于应该改的情况。

6.2 用配置矩阵管理组合爆炸

设备多了之后，测试组合会爆炸。三种设备每个两种配置，理论上有八种组合，实际测试不可能全跑。我的办法是维护一个配置矩阵，只测矩阵上的关键点。

矩阵的选择依据是"覆盖主要的变化维度"，而不是穷举。设备类型维度上，基础型和高速型覆盖了周期差异；数量维度上，单设备和多设备覆盖了仲裁逻辑；异常维度上，断连覆盖了恢复路径。这五个组合跑一遍大概四十分钟，能覆盖绝大多数结构性回归。

配置矩阵还有个附带好处：它是文档。新人接手的时候，看这五条配置就知道系统支持哪些形态、重点在哪里，比读代码快得多。

6.3 版本兼容与灰度回退

模块化结构在版本管理上有天然优势，但也带来一个新问题：模块可以独立升级，就存在版本组合不兼容的情况。我的处理方式是给契约加版本号，而不是给模块加版本号。

具体做法是：contracts/目录下的每个接口定义带一个语义版本号，模块在bind阶段声明自己实现的契约版本。运行时做兼容性检查，主版本号不一致直接拒绝启动，次版本号不一致给出警告但允许启动，补丁版本号忽略。这个规则很粗糙，但足够用，而且不需要维护复杂的依赖图。

灰度回退的实践是：新适配器上线时，配置文件里保留旧适配器的定义，通过一个开关切换。发现异常时改一行配置切回去，不需要重新部署。这个做法在早期被我嘲笑过"不够优雅"，后来真出过一次问题——新适配器在现场某台设备的固件版本上握手失败——改配置花了两分钟，如果是重新构建部署，至少两小时。

配置层面的回退开关，成本几乎为零，收益在出问题那一刻才知道有多大。建议所有关键模块都保留一个。

最后分享一点我自己的体会。这套结构最早是为了少改代码，做到后面发现最大的收获其实是排查效率——当每个模块的职责和禁止事项都是明确的时候，问题一出现，能排查的范围立刻缩小到一两个文件。我最近一次处理现场异常，从拿到日志到定位到具体模块只用了十几分钟，靠的不是经验，而是结构本身把可能性排除掉了。如果你现在正被一个两千行的驱动文件折磨，不用一次性重构成理想状态，先从"把状态通道和控制通道分开"这一步做起，改动量最小，收益最直接。