1. 为什么我要用AI原生思路重写一个Modbus仿真器
搞工业自动化和物联网的朋友对Modbus协议肯定不陌生。这东西诞生于上世纪七十年代，按理说早该进博物馆了，但现实是——你去任何一个工厂车间、配电房、水处理站转一圈，Modbus RTU和Modbus TCP还在勤勤恳恳地跑着。PLC、变频器、智能电表、温控仪表，十台设备里至少有六台在说Modbus方言。问题也随之而来：调试阶段没有真实从站设备怎么办？上位机软件开发完了，硬件还没到货怎么办？现场设备参数被锁死，想模拟一个异常响应测试容错逻辑怎么办？
这些场景我都遇到过。早些年我的做法是手写一个Python脚本，用pymodbus库搭个简易从站，寄存器地址硬编码，功能码只实现03和06，凑合能用但每次都要改代码。后来也试过一些现成的Modbus从站模拟工具，要么是Windows平台的图形化软件，配置繁琐且不跨平台；要么是商业软件，授权费用不低，想批量模拟多个从站还得加钱。直到大语言模型和AI辅助编程工具真正成熟起来，我才意识到：Modbus仿真器这类“需求明确、协议固定、边界清晰”的工具，恰恰是AI原生开发模式的最佳试验田。
所谓“AI原生开发”，我的理解不是简单地在写代码时用AI补全几行，而是从需求拆解、架构设计、协议实现到测试用例生成，整个开发流程都以“与AI协作”为核心范式来组织。你负责定义问题边界和验收标准，AI负责生成实现骨架和边界情况处理，你再负责审查、修正和集成。这套打法用在Modbus仿真器上，效果出奇地好——原本需要两三天才能打磨稳定的工具，现在一个下午就能跑通全功能码覆盖，而且代码质量比我手写的还规整。
这篇文章我会把整个开发过程拆开揉碎讲清楚。从Modbus协议的核心机制回顾，到仿真器的架构设计决策，再到用AI辅助生成代码的具体操作步骤，最后是实测中踩过的坑和排查技巧。不管你是刚接触工业协议的软件开发者，还是想用AI提效的自动化工程师，应该都能从中找到可以直接抄作业的东西。文章里涉及的所有代码和配置，你都可以在自己的环境里复现，不需要任何特殊硬件。
2. Modbus仿真器到底要仿真什么：协议核心机制拆解
2.1 从站设备的数据模型：四种寄存器到底怎么区分
很多人写Modbus仿真器时第一个卡住的地方就是：四种寄存器类型到底有什么区别，我的仿真器需要全部实现吗？这个问题不搞清楚，后面代码写出来一定是乱的。我用一个生活化的类比来解释：把Modbus从站想象成一栋办公楼，四种寄存器就是四种不同权限的房间。
线圈（Coil）相当于楼里的电灯开关，每个开关只有“开”和“关”两种状态，对应布尔量的0和1。你只能远程控制它开或关，不能问它“你现在有多亮”。功能码01读线圈，05写单个线圈，15写多个线圈。
离散输入（Discrete Input）相当于楼里的烟雾报警器，也是只有“正常”和“报警”两种状态，但它是只读的。你只能看它当前状态，不能远程把它按下去。功能码02读离散输入。
保持寄存器（Holding Register）相当于楼里的空调温控面板，每个面板上有一个16位数值，你可以读当前设定温度，也可以远程修改它。这是Modbus里最常用的寄存器类型，功能码03读保持寄存器，06写单个保持寄存器，16写多个保持寄存器。
输入寄存器（Input Register）相当于楼里的电表读数，也是16位数值，但只读。你只能读取当前电量，不能远程篡改。功能码04读输入寄存器。
| 寄存器类型 | 数据宽度 | 读写权限 | 常用功能码 | 典型设备映射 |
|---|---|---|---|---|
| 线圈 Coil | 1 bit | 读写 | 01/05/15 | 继电器输出、阀门开关 |
| 离散输入 DI | 1 bit | 只读 | 02 | 限位开关、报警触点 |
| 保持寄存器 HR | 16 bit | 读写 | 03/06/16 | 设定值、PID参数 |
| 输入寄存器 IR | 16 bit | 只读 | 04 | 测量值、电量读数 |
仿真器要做的，就是为这四类寄存器各开辟一块内存区域，然后根据收到的功能码去对应的区域执行读或写操作。听起来简单，但实际实现时有几个细节必须注意：寄存器地址的起始编号问题——Modbus协议文档里经常用1-based编号（比如40001表示第一个保持寄存器），但协议报文里用的是0-based地址（0x0000）。仿真器内部统一用0-based，对外展示时可以加偏移量转换，这个转换逻辑如果搞混，调试时会出现“读到的值总是差一位”的诡异现象。
2.2 功能码的请求响应格式：PDU结构逐字节拆解
Modbus的通信单元叫PDU（Protocol Data Unit），结构极其简洁：功能码占1字节，后面跟数据字段。以最常用的读保持寄存器（功能码03）为例，请求PDU是5字节：功能码(1B) + 起始地址(2B) + 寄存器数量(2B)。响应PDU是：功能码(1B) + 字节数(1B) + 寄存器值(N×2B)。
我拿一个实际例子走一遍。上位机要读从站地址0x0000开始的2个保持寄存器，请求报文（RTU模式，不含CRC）是：03 00 00 00 02。从站如果寄存器0x0000的值是0x1234，0x0001的值是0x5678，响应就是：03 04 12 34 56 78。其中04表示后面跟4个字节的数据。
写单个寄存器（功能码06）的请求是：功能码(1B) + 寄存器地址(2B) + 写入值(2B)，响应是原样回显请求。写多个寄存器（功能码16）的请求是：功能码(1B) + 起始地址(2B) + 寄存器数量(2B) + 字节数(1B) + 数据(N×2B)，响应是：功能码(1B) + 起始地址(2B) + 寄存器数量(2B)。
异常响应是所有功能码共用的格式：功能码最高位置1（即原功能码+0x80），后面跟1字节异常码。比如功能码03的异常响应是0x83，异常码01表示“非法功能”，02表示“非法数据地址”，03表示“非法数据值”。仿真器必须正确处理这些异常场景，否则上位机的容错逻辑根本没法测试。
注意：很多初学者写的仿真器收到不支持的地址范围时直接不响应，导致上位机超时。正确做法是返回异常码02，让上位机立刻知道是地址问题而不是通信中断。
2.3 RTU与TCP两种传输模式的差异处理
Modbus RTU跑在串口上，报文帧之间用至少3.5个字符时间的静默间隔来分隔，帧尾有2字节CRC校验。Modbus TCP跑在以太网上，报文前面加了7字节的MBAP头（事务标识2B + 协议标识2B + 长度2B + 单元标识1B），没有CRC校验，因为TCP本身保证了数据完整性。
仿真器如果要同时支持两种模式，最干净的做法是把协议解析层和传输层彻底分离。传输层负责收字节流、切分完整帧、校验（RTU的CRC）、去掉帧头帧尾，然后把纯PDU交给协议层。协议层只认PDU，不关心这PDU是从串口来的还是从网口来的。这样代码复用率最高，测试也最方便——你可以直接构造PDU字节数组来单元测试协议层，不需要真的开串口或建TCP连接。
我在实际项目里就是这么分层的。传输层用Python的serial库处理RTU，用socket库处理TCP，协议层是一个纯函数式的handle_pdu(pdu_bytes) -> response_bytes。这个设计决策后面会详细展开。
3. AI原生开发流程：从需求到可运行仿真器的完整路径
3.1 需求拆解：先让AI帮你把边界条件列全
我一开始只跟AI说“帮我写一个Modbus TCP从站仿真器”，结果生成的代码只实现了功能码03，其他功能码全是pass。这就是需求描述太粗导致的。后来我换了一种方式：先让AI扮演一个挑剔的测试工程师，把Modbus仿真器可能遇到的所有场景列出来。
我给AI的提示词大意是：“我要开发一个Modbus从站仿真器，支持RTU和TCP两种模式，支持功能码01/02/03/04/05/06/15/16。请你列出这个仿真器需要处理的所有边界情况和异常场景，包括但不限于地址越界、数量越界、功能码不支持、数据值非法、并发访问冲突等。”
AI返回了一个相当完整的清单，我整理后得到下面这张表。这张表后来成了我的验收标准，每实现一个功能就对照检查。
| 场景类别 | 具体场景 | 期望行为 |
|---|---|---|
| 地址越界 | 起始地址+数量超过寄存器区大小 | 返回异常码02 |
| 数量越界 | 读取数量为0或超过125（读）或123（写） | 返回异常码03 |
| 功能码不支持 | 收到0x08等未实现功能码 | 返回异常码01 |
| 数据值非法 | 写线圈时值不是0x0000或0xFF00 | 返回异常码03 |
| 并发访问 | 多个客户端同时读写同一寄存器 | 加锁保证原子性 |
| 帧不完整 | TCP收到半包或RTU帧间隔不对 | 丢弃或等待 |
| CRC错误 | RTU帧CRC校验失败 | 静默丢弃 |
| 单元标识不匹配 | TCP的Unit ID与配置不符 | 静默丢弃或响应异常 |
有了这张表，后面写代码和测试就有了明确靶子。这也是AI原生开发的一个核心心法：把AI当需求分析师用，比当代码生成器用价值更大。
3.2 架构设计：为什么我选择“传输层-协议层-数据层”三层分离
仿真器的架构我反复调整过三版。第一版是面向过程的一坨代码，RTU和TCP的逻辑混在一起，改一个功能码要动三处地方。第二版尝试用类继承，基类处理公共逻辑，RTU和TCP子类各自实现传输，但协议处理还是散落在各处。第三版才定下来现在这个三层结构，我觉得是最好维护的。
数据层：一个RegisterBank类，内部维护四个数组——coils（布尔列表）、discrete_inputs（布尔列表）、holding_registers（整数列表）、input_registers（整数列表）。所有读写操作都通过这个类的方法进行，内部用threading.Lock保证线程安全。这个类不关心Modbus协议，只提供read_coils(addr, count)、write_holding(addr, value)这样的接口。
协议层：一个ModbusProtocol类，核心方法是handle_pdu(pdu: bytes) -> bytes。它解析功能码，调用数据层的对应方法，然后组装响应PDU。异常处理也在这层，根据数据层返回的错误类型映射到对应的异常码。
传输层：两个类，RTUServer和TCPServer。RTU这边用serial.Serial打开串口，循环读取字节，用状态机切分帧，校验CRC，提取PDU交给协议层，拿到响应后加CRC发回去。TCP这边用socket监听端口，每个客户端连接开一个线程，读取MBAP头确定长度，提取PDU交给协议层，拿到响应后加MBAP头发回去。
这个分层的好处是：协议层的单元测试完全不需要真实串口或网络。我可以直接构造03 00 00 00 02这样的字节数组，调用handle_pdu，断言返回的字节数组符合预期。传输层的测试则可以用虚拟串口对（比如socat创建的PTY对）或本地TCP回环，不需要真实硬件。
3.3 用AI生成代码骨架：提示词怎么写才有效
这是整篇文章最核心的部分。我试过很多种提示词写法，最后总结出一个高效模板：角色设定 + 接口定义 + 边界条件 + 输出格式。
以协议层的handle_pdu方法为例，我的提示词是这样的：
你是一个资深的工业协议开发者。请用Python实现一个Modbus PDU处理函数，签名是
handle_pdu(self, pdu: bytes) -> bytes。输入是完整的PDU字节串（功能码+数据），输出是响应PDU字节串。需要支持功能码01、02、03、04、05、06、15、16。数据层接口如下：read_coils(addr, count) -> list[bool]、read_discrete_inputs(addr, count) -> list[bool]、read_holding_registers(addr, count) -> list[int]、read_input_registers(addr, count) -> list[int]、write_coil(addr, value: bool)、write_holding_register(addr, value: int)、write_coils(addr, values: list[bool])、write_holding_registers(addr, values: list[int])。数据层方法在地址越界时抛出IllegalDataAddressError，在数量越界时抛出IllegalDataValueError。请处理所有异常并返回对应的异常响应PDU。输出完整的Python类代码，包含必要的注释。
AI生成的代码质量相当高，功能码03的处理逻辑大致是这样的：
def _handle_read_holding_registers(self, pdu: bytes) -> bytes: if len(pdu) != 5: return self._exception_response(0x03, 0x03) start_addr = struct.unpack('>H', pdu[1:3])[0] quantity = struct.unpack('>H', pdu[3:5])[0] if quantity < 1 or quantity > 125: return self._exception_response(0x03, 0x03) try: values = self.register_bank.read_holding_registers(start_addr, quantity) except IllegalDataAddressError: return self._exception_response(0x03, 0x02) byte_count = quantity * 2 response = struct.pack('>B B', 0x03, byte_count) for v in values: response += struct.pack('>H', v) return response这段代码我几乎没改就直接用了。AI还自动处理了quantity为0的情况，这是我一开始没想到的边界。当然也有需要修正的地方：AI最初把异常响应的功能码写成了0x03 + 0x80，但Python里0x03 + 0x80是0x83没错，可如果功能码是0x10，0x10 + 0x80是0x90，也是对的。这个逻辑没问题，我多虑了。
3.4 测试用例生成：让AI帮你写pytest
代码写完了，怎么验证？手写测试用例太慢，我直接让AI根据前面那张边界条件表生成pytest测试代码。提示词是：“根据以下边界条件表，为handle_pdu方法生成pytest测试用例，每个用例包含输入PDU和期望输出PDU，覆盖正常读写和所有异常场景。”
AI生成的测试代码有三十多个用例，我挑几个典型的展示：
def test_read_holding_registers_normal(protocol): protocol.register_bank.holding_registers[0] = 0x1234 protocol.register_bank.holding_registers[1] = 0x5678 pdu = bytes([0x03, 0x00, 0x00, 0x00, 0x02]) response = protocol.handle_pdu(pdu) assert response == bytes([0x03, 0x04, 0x12, 0x34, 0x56, 0x78]) def test_read_holding_registers_address_out_of_range(protocol): pdu = bytes([0x03, 0xFF, 0xFF, 0x00, 0x01]) response = protocol.handle_pdu(pdu) assert response == bytes([0x83, 0x02]) def test_write_single_coil_invalid_value(protocol): pdu = bytes([0x05, 0x00, 0x00, 0x12, 0x34]) response = protocol.handle_pdu(pdu) assert response == bytes([0x85, 0x03])跑一遍pytest -v，三十多个用例全绿，心里就有底了。这里有个经验：AI生成的测试用例偶尔会有断言写错的情况，比如把异常码02和03搞混。所以测试跑失败时，先别急着改代码，先检查测试用例本身对不对。我遇到过两次，都是AI把期望值写错了，代码逻辑其实没问题。
4. 实操过程：从零跑通一个双模式Modbus仿真器
4.1 环境准备与依赖安装
我用的环境是Python 3.10，操作系统不限，Windows、Linux、macOS都能跑。依赖只有两个：pyserial用于RTU串口通信，pytest用于测试。TCP部分用标准库socket就够了，不需要额外安装。
pip install pyserial pytest如果你没有真实串口，可以用socat创建一对虚拟串口来测试RTU模式。Linux下：
socat -d -d pty,raw,echo=0 pty,raw,echo=0这条命令会输出两个PTY设备路径，比如/dev/pts/3和/dev/pts/4。仿真器打开其中一个，你的测试客户端打开另一个，就能模拟完整的串口通信。Windows下可以用com0com这类虚拟串口工具，原理一样。
提示：虚拟串口对在调试时非常有用，但要注意
socat创建的PTY默认没有硬件流控，如果你的仿真器代码里开了RTS/CTS，可能会卡住。建议仿真器默认关闭流控。
4.2 数据层实现：寄存器区的初始化与线程安全
数据层的代码不复杂，但有几个细节值得说。首先是寄存器区的默认大小，我设的是线圈和离散输入各1000个，保持寄存器和输入寄存器各1000个。这个大小可以配置，但1000对于绝大多数调试场景足够了。如果你要模拟大型PLC，可以调到10000甚至更大，内存占用也就是几十KB的事。
初始化时，我习惯给保持寄存器填一些有规律的值，比如地址0x0000填0x0001，地址0x0001填0x0002，依次递增。这样调试时一眼就能看出读到的数据对不对，比全零好排查。输入寄存器则填一些模拟的测量值，比如0x0000填0x0064（表示100），0x0001填0x00C8（表示200）。
线程安全方面，我用了一个threading.RLock。为什么用RLock而不是Lock？因为有些复合操作可能需要在一个锁内调用另一个也加锁的方法，用RLock可以避免死锁。比如write_holding_registers内部循环调用write_holding_register，如果两个方法都加锁且用的是普通Lock，就会死锁。
class RegisterBank: def __init__(self, size=1000): self.coils = [False] * size self.discrete_inputs = [False] * size self.holding_registers = [0] * size self.input_registers = [0] * size self._lock = threading.RLock() for i in range(size): self.holding_registers[i] = i + 1 self.input_registers[i] = (i + 1) * 100 def read_holding_registers(self, addr, count): with self._lock: if addr < 0 or addr + count > len(self.holding_registers): raise IllegalDataAddressError() return self.holding_registers[addr:addr + count]4.3 协议层实现：功能码分发与异常映射
协议层的核心是一个字典，把功能码映射到对应的处理方法。这样新增功能码只需要加一个键值对，不用改handle_pdu的主逻辑。
class ModbusProtocol: def __init__(self, register_bank): self.register_bank = register_bank self.handlers = { 0x01: self._handle_read_coils, 0x02: self._handle_read_discrete_inputs, 0x03: self._handle_read_holding_registers, 0x04: self._handle_read_input_registers, 0x05: self._handle_write_single_coil, 0x06: self._handle_write_single_register, 0x0F: self._handle_write_multiple_coils, 0x10: self._handle_write_multiple_registers, } def handle_pdu(self, pdu): if len(pdu) < 1: return b'' func_code = pdu[0] handler = self.handlers.get(func_code) if handler is None: return self._exception_response(func_code, 0x01) try: return handler(pdu) except IllegalDataAddressError: return self._exception_response(func_code, 0x02) except IllegalDataValueError: return self._exception_response(func_code, 0x03)异常映射这块有个容易忽略的点：异常响应的功能码是原功能码加0x80。比如功能码0x10的异常响应是0x90。这个逻辑我封装在_exception_response里，传入原功能码和异常码，内部做加法。
写多个线圈（功能码0x0F）的请求格式稍微复杂一点：功能码(1B) + 起始地址(2B) + 线圈数量(2B) + 字节数(1B) + 线圈状态(N字节)。线圈状态是按位打包的，第一个字节的bit0对应起始地址的线圈，bit1对应下一个，以此类推。解析时需要逐位提取，写入时再逐位打包。这块AI生成的代码一开始有个bug：当线圈数量不是8的倍数时，最后一个字节的多余位没有忽略，导致写入越界。我修正的方式是在循环里加一个计数器，达到数量就break。
4.4 传输层实现：RTU帧切分与TCP连接管理
RTU的帧切分是仿真器里最考验细节的部分。Modbus RTU规定帧间隔至少3.5个字符时间，在9600波特率下大约是4毫秒。实际实现时，我用一个简单的超时机制：收到第一个字节后启动一个定时器，如果超过4毫秒没有新字节到来，就认为一帧结束。Python的serial库可以设置timeout参数，我设的是0.005秒，然后在循环里累积字节。
class RTUServer: def __init__(self, port, baudrate, protocol): self.ser = serial.Serial(port, baudrate, timeout=0.005) self.protocol = protocol def run(self): buffer = b'' while True: data = self.ser.read(256) if data: buffer += data elif buffer: if len(buffer) >= 4: pdu = buffer[:-2] crc = buffer[-2:] if self._check_crc(pdu, crc): response = self.protocol.handle_pdu(pdu) if response: self.ser.write(response + self._calc_crc(response)) buffer = b''TCP这边相对简单，因为TCP是流式协议，需要自己处理粘包和半包。我的做法是：先读7字节的MBAP头，从中解析出长度字段，再读剩余的长度字节。如果一次recv返回的数据不够，就继续读直到凑够。每个客户端连接开一个独立线程，用threading.Thread管理。
class TCPServer: def __init__(self, host, port, protocol): self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.sock.bind((host, port)) self.sock.listen(5) self.protocol = protocol def _handle_client(self, conn): while True: mbap = self._recv_exact(conn, 7) if not mbap: break length = struct.unpack('>H', mbap[4:6])[0] pdu = self._recv_exact(conn, length - 1) if not pdu: break response = self.protocol.handle_pdu(pdu) if response: resp_mbap = mbap[:4] + struct.pack('>H', len(response) + 1) + mbap[6:7] conn.sendall(resp_mbap + response) conn.close()注意：TCP的MBAP头里有个单元标识（Unit ID），在Modbus TCP转RTU的网关场景里用来区分后端RTU从站。纯TCP仿真器可以忽略这个字段，但最好保留并原样返回，否则某些上位机可能会报错。
4.5 启动与联调：用Modbus Poll和pymodbus客户端验证
仿真器写完了，怎么验证它真的能用？我一般用两个工具交叉验证。一个是Modbus Poll（Windows下的图形化主站工具），配置好IP和端口后直接读寄存器，看数值对不对。另一个是Python的pymodbus客户端，写几行脚本自动化测试。
from pymodbus.client import ModbusTcpClient client = ModbusTcpClient('127.0.0.1', port=5020) client.connect() result = client.read_holding_registers(0, 10, unit=1) print(result.registers) client.write_register(0, 999, unit=1) result = client.read_holding_registers(0, 1, unit=1) print(result.registers) client.close()跑通之后，你会看到第一次打印[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]，第二次打印[999]。这说明读写都正常。如果读出来全是0或者报异常，就对照前面的边界条件表逐项排查。
RTU模式的验证稍微麻烦一点，需要两个虚拟串口。仿真器打开/dev/pts/3，pymodbus客户端打开/dev/pts/4，配置相同的波特率和校验方式。我实测下来，9600波特率下读写100个寄存器大约需要200毫秒，响应速度完全满足调试需求。
5. 踩坑记录与排查技巧实录
5.1 寄存器地址偏移：为什么读到的值总是差一位
这是我踩过最多次的坑，没有之一。Modbus协议文档里经常用1-based编号描述寄存器，比如“40001”表示第一个保持寄存器。但协议报文里用的是0-based地址，40001对应的报文地址是0x0000。如果你在仿真器里把40001直接当成地址0x0001来处理，上位机读40001时就会读到第二个寄存器的值。
我的解决方案是在仿真器的配置里加一个address_offset参数，默认0。如果你的上位机用的是1-based编号，就把offset设成-1，仿真器内部统一转成0-based。这个参数在联调时非常有用，能省去大量“为什么值不对”的困惑。
提示：不同厂商的Modbus文档对地址的描述方式不一样，有的用40001，有的用0x0000，有的用十进制0。拿到文档第一件事就是确认它的地址基准是什么，然后在仿真器里做对应转换。
5.2 字节序问题：大端小端在16位和32位数据上的表现
Modbus协议规定寄存器内部是大端序（高字节在前），但32位浮点数或32位整数要跨两个寄存器存储时，字节序就有多种排列方式了。常见的有ABCD（大端）、CDAB（小端字交换）、BADC（字节交换）、DCBA（全小端）。仿真器如果只处理16位数据，不用操心这个；但如果要模拟浮点数寄存器，就必须支持字节序配置。
我的做法是在数据层加一个byte_order参数，读取时根据配置重新排列字节。比如ABCD模式下，寄存器0x0000存高16位，0x0001存低16位；CDAB模式下反过来。这个功能在模拟电表、流量计等设备时特别重要，因为这些设备的浮点数格式五花八门。
5.3 并发访问冲突：多客户端同时读写同一寄存器
TCP仿真器支持多客户端连接，如果两个客户端同时写同一个寄存器，不加锁的话可能出现数据竞争。Python的GIL在字节码层面保证了原子性，但read-modify-write这种复合操作不是原子的。比如客户端A读寄存器0得到100，准备写101；同时客户端B读寄存器0也得到100，准备写102。最终结果可能是101或102，取决于谁后写，但两个客户端都以为自己写成功了。
我在数据层的每个写方法里都加了锁，保证read-modify-write序列的原子性。另外，对于批量写操作，整个批次用一个锁保护，避免写到一半被另一个客户端插入。实测下来，10个客户端并发读写1000次，没有出现数据不一致的情况。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 上位机连接超时 | 仿真器未启动或端口被占用 | netstat -an检查端口监听 | 换端口或杀掉占用进程 |
| 读到的值全为0 | 寄存器区未初始化或地址偏移错误 | 打印仿真器内部寄存器数组 | 检查初始化逻辑和offset配置 |
| 写操作无响应 | 功能码未实现或PDU长度校验失败 | 抓包看请求PDU | 补全功能码或修正长度校验 |
| RTU通信乱码 | 波特率/校验位/停止位不匹配 | 确认双方串口参数 | 统一配置为9600-8-N-1 |
| TCP粘包导致解析错误 | 未按MBAP长度字段读取 | 打印每次recv的字节数 | 用_recv_exact确保读满 |
| 异常响应码不对 | 异常映射逻辑错误 | 对照协议文档检查异常码 | 修正_exception_response |
| 多客户端时数据错乱 | 未加锁或锁粒度不对 | 并发测试复现 | 数据层加RLock |
| 浮点数解析错误 | 字节序配置不对 | 用已知浮点数测试 | 调整byte_order参数 |
这张表是我在实际调试中一点点攒出来的，每次遇到新问题就加一行。现在基本上看到现象就能定位到原因，省去了大量试错时间。
5.5 性能优化：从单线程到多线程的取舍
最初的TCP仿真器是单线程的，一个客户端连接处理完才处理下一个。调试时够用，但做压力测试时就不行了——10个客户端轮流连接，每个都要等前一个断开。后来改成每个连接一个线程，并发能力上来了，但线程数太多时上下文切换开销也不小。
我的折中方案是：用threading.Thread处理连接，但限制最大并发连接数为50。超过50个连接时，新连接排队等待。对于Modbus仿真器来说，50个并发客户端已经远远超过实际调试需求了。如果你需要模拟上千个从站，那应该用异步IO（asyncio）而不是多线程，但那是另一个话题了。
RTU这边不存在并发问题，因为串口是独占的。但要注意串口读写缓冲区的大小，默认的serial缓冲区可能不够大，高速通信时容易丢数据。我一般把write_timeout设成1秒，read_buffer_size设成4096，实测在115200波特率下连续读写10分钟无丢包。
6. 后续扩展方向与个人体会
这个仿真器目前支持的功能码覆盖了Modbus最常用的读写场景，但还有一些扩展空间。比如功能码07（读异常状态）、08（诊断）、11（获取通信事件计数器）这些诊断类功能码，在模拟某些老设备时可能会用到。另外，Modbus RTU over TCP这种变体也值得支持——有些网关设备就是把RTU帧直接封装在TCP里传输，没有MBAP头。
我还想加一个Web界面，用简单的HTML表格展示寄存器当前值，支持在线修改。这样调试时不用开Modbus Poll，浏览器里就能看到数据变化。技术上用Flask或FastAPI搭一个轻量服务，通过WebSocket推送寄存器更新，应该不难实现。
最后分享一个我在AI原生开发中体会最深的心得：AI生成的代码质量取决于你给它的约束条件有多清晰。你告诉它“写一个Modbus仿真器”，它给你一个玩具；你告诉它“实现功能码03，输入PDU格式是XX，输出PDU格式是YY，地址越界抛异常码02，数量越界抛异常码03”，它给你一段可以直接上生产的代码。把AI当实习生用，你得把需求文档写清楚；把AI当资深工程师用，你得把架构和接口定义好。这个仿真器从需求拆解到跑通测试，我实际投入的时间不到四个小时，其中大部分时间花在定义接口和审查AI生成的边界处理上，真正写代码的时间很少。这个效率提升是实实在在的。
