X-Plane 11 UDP通信协议解析与外置仪表开发避坑

简介一份面向飞行模拟器二次开发者的中文说明文档聚焦 X-Plane 11兼容 X-Plane 10 思路的 UDP 通信机制适合需要将飞行模拟器与自研视觉系统、移动地图、自制座舱或运动平台对接的读者。文档围绕端口 49000 的收发规则展开梳理 ACFN、PREL、ACPR 等消息类型以及 RPOS 位置输出、字符串空值终止、网络数据转储到 log.txt 与 error.out 排错等细节并给出插件与 UDP 两种实现路径的取舍便于读者按需选择数据驱动或监听方式。资源包内含 1 个 docx 文件约 44KB体量轻便适合作为手边速查手册内容以消息列表、字段说明和使用提示组织便于按关键字定位接口。目前已有 2063 人学习说明该主题在飞行模拟器外设与数据交互场景中具有一定关注度。读者可从中获得 UDP 消息类型与数据格式的系统梳理、常见配置注意事项及联调排错线索用于搭建自己的数据收发程序或快速核对接口字段减少协议理解与试错成本。1. 从一块自制姿态仪说起去年帮人调一块自制的座舱姿态仪单片机跑好了屏幕点起来了卡在数据源上。他先在插件 SDK 上折腾了两天编译环境、头文件版本、加载顺序一路翻车最后我让他换个思路把 X-Plane 11 的 UDP 通信打开往 49000 端口发一行订阅命令试试。他写了二十来行 socket 代码半小时后姿态角就在屏幕上动了。这件事说明一个很多人绕远路的点——不一定非要写插件X-Plane 11 的 UDP 通信协议本身就够你做外置仪表、移动地图、运动平台甚至自研视景。这份中文说明文档干的就是这件事它把 X-Plane 10 到 11 之间被废弃、被替换的消息逐条标出来再把 11 里仍然有效的消息类型、结构体布局、字节对齐规则摊开讲。适合两类人手里有硬件或外部程序、想把模拟器当数据源或渲染器的开发者以及刚接手一套老 UDP 代码、发现从 V10 升上来之后一堆消息不认的维护者。端口固定、格式固定、不依赖插件是它最大的价值。2. 协议底座49000 端口上的 5 字符前言与结构对齐规则动手之前得先把这层壳剥开。X-Plane 的 UDP 协议没有握手、没有会话、没有重传就是一堆裸包在 49000 端口上进进出出。所有复杂度都集中在两个地方包头怎么拼结构体怎么摆。这两件事搞错一个你发出去的包在模拟器眼里就是一堆噪声而且它不会报错只会安静地丢掉。2.1 一条消息的最小骨架4 个字母加一个 0 字节协议规定得极其朴素前 4 个字符是消息类型标签第 5 个字节是一个值为 0 的字节后面紧跟数据区。这个 0 字节的作用是把标签做成 C 风格的空值终止字符串方便对面直接当字符串比较。所以一条完整消息长得像RPOS\0 数据。有几个规则必须刻在脑子里X-Plane始终在 49000 端口接收这个端口号不可配置。你发的任何字符串字段都必须空值终止少一个\0整包作废。回包不回到 49000而是回到你发送这条命令时的源 IP 和源端口。这意味着你的客户端必须 bind 一个固定端口并一直守着不能发完就关 socket。文档里反复提到一个设计取舍有些数值参数用字符串传比如用60表示每秒 60 次而不是传二进制整数。理由很直白——避开大小端转换的麻烦。这是那个年代跨平台代码的典型妥协今天看有点土但确实省事。拼包的逻辑用代码表达就是这样注意标签后面那个b\x00import socket XP_HOST 127.0.0.1 XP_PORT 49000 def build_packet(tag: str, payload: bytes b) - bytes: 按协议拼一条 UDP 消息4 字节标签 1 字节 0x00 数据区 assert len(tag) 4, 标签必须是 4 个字符 return tag.encode(ascii) b\x00 payload sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((0.0.0.0, 49001)) # 必须固定源端口回包靠它找回来 # 订阅位置输出RPOS 60 空值终止表示每秒回 60 次 sock.sendto(build_packet(RPOS, b60\x00), (XP_HOST, XP_PORT))build_packet里那个断言不是摆设标签长度写错是最常见的手误。bind那行更关键很多人图省事不 bind让系统随机分配源端口结果发现模拟器回包全丢了——不是没发是发到了一个已经关闭的端口上。我一般会把客户端端口和模拟器端口写进配置两边都固定死。2.2 XCHR / XINT / XFLT / XDOB 与 Intel 64 位对齐陷阱文档里定义了四个基础类型别名直接对应 C 里的四种宽度别名实际类型宽度对齐边界XCHRchar1 字节1XINTint4 字节4XFLTfloat4 字节4XDOBdouble8 字节8真正的坑在结构体对齐。文档写得很明确字节对齐必须匹配 Intel 64 位环境下编译器的行为也就是整数和浮点按最近的 4 字节边界对齐双精度按最近的 8 字节边界对齐。由此产生两个反直觉的后果第一一个 4 字节 int 后面如果跟 double这个 int 实际会占 8 字节中间 4 字节是编译器塞的填充。第二数组里只有第一个元素会被推到对齐边界上后面每个元素仍然按自身宽度紧凑排列不会逐个补齐。拿文档里的飞机加载结构举例int char[150] int这种组合字符数组结束后偏移是 154而下一个 int 需要 4 字节对齐154 不是 4 的倍数所以要补 2 字节整体大小变成 160 而不是 1544158。这种差 2 字节的偏差在你用脚本语言拼包时就是致命伤因为脚本语言的打包函数默认往往是不填充的。提示判断自己有没有踩对齐坑最快的办法是把模拟器里那个「转储网络数据到 log.txt」的开关打开发一包退出翻日志。文档说它会写出模拟器期望的结构大小和你实际发的大小两个数字对不上就是填充算错了。2.3 用 40 行 Python 打通第一条回路第一次接触这套协议建议先别急着做业务用最小的代码验证通路。下面这段是接收 RPOS 回包并解析的完整骨架跑通了再往上叠功能。import socket import struct # RPOS 回包3 个 double 10 个 float紧凑排列共 64 字节 # 表示小端3d 3 个 double10f 10 个 float RPOS_FMT 3d10f RPOS_SIZE struct.calcsize(RPOS_FMT) # 24 40 64 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((0.0.0.0, 49001)) sock.settimeout(3.0) sock.sendto(bRPOS\x0060\x00, (127.0.0.1, 49000)) for _ in range(5): data, addr sock.recvfrom(2048) if not data.startswith(bRPOS): continue body data[5:] # 跳过 5 字节前言 assert len(body) RPOS_SIZE, f长度不对{len(body)} lon, lat, ele, agl, the, psi, phi, vx, vy, vz, p, q, r \ struct.unpack(RPOS_FMT, body) print(flon{lon:.6f} lat{lat:.6f} ele{ele:.1f}m fpitch{the:.2f} roll{phi:.2f} hdg{psi:.2f})三个地方值得说。struct.calcsize一定要跑一遍打印出来别凭感觉算。data[5:]这个切片是跳过前言的固定动作回包同样带 5 字节头忘了跳就会拿标签字节去解 double出来的数全是天文数字。settimeout是必须的UDP 收不到包不会报错只会永远阻塞。这里用的是小端紧凑格式因为 RPOS 这个结构恰好没有对齐空洞3 个 double 在前后面全是 float整体 64 字节是 8 的倍数紧凑格式和 C 对齐格式结果一致。换到 VEHX 那种int double混排的结构就不能这么写后面会专门说。3. 输出链路RPOS / RADR / FLIR 把飞行状态推给外部程序协议里最常用的方向是从模拟器往外拿数据。文档把这条链路拆成三条独立的订阅通道每条用一条 5 字符命令开启开启后模拟器按你指定的频率主动往你的源地址推包。三条通道互不干扰可以同时开。订阅命令的格式统一是标签 数字字符串 空值终止。数字的含义是频率——但三条通道对「频率」的解释并不一样这一点文档分得很散容易看漏。3.1 RPOS一次订阅每秒 N 次的位置姿态包RPOS 是最经典的一条用来驱动移动地图或者外部视景。发RPOS\0 60\0模拟器就每秒回 60 个包。数据区是紧凑排列的没有任何填充总共 64 字节字段类型含义单位londouble经度度latdouble纬度度eledouble海拔高度米y_agl_mtrfloat离地高度米veh_the_locfloat俯仰度veh_psi_locfloat真航向度veh_phi_locfloat滚转度vx_wrlfloat东向速度米/秒vy_wrlfloat天向速度米/秒vz_wrlfloat南向速度米/秒Pradfloat滚转角速度弧度/秒Qradfloat俯仰角速度弧度/秒Rradfloat偏航角速度弧度/秒注意坐标系的方向约定速度是「东-上-南」而不是常见的「北-东-地」角度单位是度而角速度单位是弧度。这两个不统一的地方坑过不少人我第一次做运动平台的时候把 vz 当成北向速度接进去平台往反方向倒查了一下午才发现是坐标系问题。文字版和字符串版都要用同一个解析逻辑所以解析函数最好单独抽出来别塞在收包循环里import struct RPOS_FMT 3d10f def parse_rpos(body: bytes) - dict: 把 RPOS 回包的数据区解析成字典注意单位混杂 v struct.unpack(RPOS_FMT, body) return { lon: v[0], lat: v[1], ele_m: v[2], agl_m: v[3], pitch_deg: v[4], heading_deg: v[5], roll_deg: v[6], v_east: v[7], v_up: v[8], v_south: v[9], p_rad: v[10], q_rad: v[11], r_rad: v[12], }字段名带上单位后缀是我踩坑之后的习惯ele_m、pitch_deg、p_rad这样写后续接硬件时至少不会把度和弧度搞混。返回字典而不是元组是因为下游往往只关心其中几个值用键取值比记索引位置靠谱得多。3.2 RADR每帧 N 个雷达点不是每秒RADR 用来驱动自绘的天气雷达。发RADR\0 10\0看起来和 RPOS 一样但那个 10 的含义变了——它表示每帧的雷达点数量不是每秒的包数。文档在这一点上只用了一句话带过非常容易误读。每个雷达点的结构是 4 个 float共 16 字节字段类型含义lonfloat雷达点经度latfloat雷达点纬度storm_levelfloat降水强度0 到 100storm_heightfloat风暴顶高度海平面以上米数一次回包会连续塞进 N 个这样的 16 字节块所以总长度是5 16 * N。解析时先算出 N再循环切片别用一个固定长度的格式串硬套RADR_PT struct.Struct(4f) # 单点 16 字节 def parse_radr(body: bytes) - list: n len(body) // RADR_PT.size pts [] for i in range(n): lon, lat, level, height RADR_PT.unpack_from(body, i * RADR_PT.size) if level 0: continue # 强度为 0 的点直接丢渲染层不需要 pts.append({lon: lon, lat: lat, level: level, top_m: height}) return ptsunpack_from配合偏移量比切片再解包省一次内存拷贝在高频循环里差别不小。跳过level 0的点是渲染层的优化雷达图上没有降水的格子画出来也没意义早丢早省事。文档提到「每帧」这个量纲实际使用中它跟模拟器的渲染帧率挂钩帧率掉了雷达刷新也跟着掉如果你的雷达界面要求稳定刷新得自己加一层插值。3.3 FLIR帧率、空值终止和二进制提取FLIR 是拿实时的红外成像画面。命令格式同样是FLIR\0 10\0这里的 10 是每秒的帧数回到和 RPOS 一致的口径上。这条通道的特殊之处在于它推的是图像单个 UDP 包放不下所以文档把它单独指到了另一份提取说明里。我在这个功能上翻过一次车以为收到的每一包就是一整帧结果拼出来的图永远是撕裂的。原因是图像数据会被拆成多包需要按帧序号自己重组还要处理丢包——UDP 不保证顺序也不保证到达丢一包就是一条横纹。常见做法是给每帧留一个缓冲区收到完整帧再交给渲染层缺包的帧直接丢弃重来宁可掉一帧也不要花屏。注意图像类通道的带宽占用远高于 RPOS把它和位置通道放在同一个 socket 上收很容易因为处理不及时导致内核缓冲区溢出表现出来就是「位置数据突然断流」。分成两个 socket 或两个独立线程处理是更稳的结构。4. 输入端ACFN / PREL / ACPR / VEHX 四种反向驱动方式反向的控制链路是这份文档里信息密度最高的部分。核心思路是你在外部算好了飞机该在哪、该朝哪把结果打包发给模拟器让它照着摆。文档按「加载飞机」「定位飞机」「两者合一」「移动已有飞机」拆成了四条消息另外还有命令和场景两条旁路。4.1 PREL31 个起始枚举怎么挑PREL 是定位消息作用是「把这架飞机放到某个新位置」。它的结构体字段多但真正需要动脑的是第一个枚举字段type_start。文档列了从 5 到 36 一共三十来个值看着吓人实际按用途能归成四类精准坐标类loc_specify_lle6直接用经纬高定位这是外部程序最常用的一种配合后面四个 double 字段使用。机场跑道类loc_ram10停机坪、loc_tak11跑道起飞、loc_vfr12/loc_ifr13进近这些走机场 ID 加跑道索引的路子。特殊场景类loc_cat19弹射、loc_tow20滑翔机牵引、loc_shuttle_glide36等属于模拟器内置的特定玩法。系统内部类loc_repeat_last5、loc_general_area7、loc_snap_load9这几个是模拟器自己用的外部程序基本不该碰。文档特别标注loc_snap_load是「从电影取快照时用不要重置飞行路径或移动飞机」。用loc_specify_lle的时候机场相关字段全部填零就行文档明确说了这种情况可以把机场信息设为零。这一点很重要因为很多人不敢填零硬塞一个机场 ID 进去结果飞机被扔到那个机场去了。结构体里的字符串字段apt_id长度取决于编译期的idDIM常量文档没给具体数字。这种长度不确定的字段最稳的做法是在 C 侧sizeof打印一遍或者用模拟器的日志功能反推期望大小别猜。4.2 ACFN 与 ACPR加载和定位合成一条消息ACFN 负责加载一架飞机结构是int p char path[150] int livery_index。p是飞机索引0 表示你正在飞的主机1 到 19 是其他飞机槽位。注意这个结构里int后面跟一个 150 字节的字符数组字符数组结束后偏移 154不满足下一个 int 的 4 字节对齐所以编译器会补 2 字节整个结构是 160 字节。文档还特意标注了 V11 的 ACFN 相比 V10 的 OLDACF 多了 livery 字段老代码直接复用会错位。ACPR 是「加载 定位」的合并版数据区就是 ACFN 结构紧接 PREL 结构。这个合并设计很实用——你从外部程序加载一架僚机并指定位置一条包就够不用发两次再做时序同步。文档用一个「AND」的写法强调这个语义翻译过来就是「加载并且定位」。def build_vehx(slot: int, lat: float, lon: float, ele: float, psi_deg: float, pitch_deg: float, roll_deg: float) - bytes: VEHX用自己的飞行模型驱动模拟器画面 结构布局Intel 64 位对齐 int slot(4) 4 字节填充 3×double(24) 3×float(12) 4 字节尾部填充 48 payload struct.pack( i4x3d3f4x, slot, lat, lon, ele, psi_deg, pitch_deg, roll_deg, ) assert len(payload) 48, len(payload) return bVEHX\x00 payload这里4x出现了两次是关键。第一个4x补在 int 和 double 之间因为 double 要求 8 字节对齐int 占了 4 字节后必须跳过 4 字节第二个4x补在结构末尾因为结构体整体大小要对齐到最大成员的对齐边界844 不是 8 的倍数补到 48。少了任何一个模拟器收到的包大小都对不上日志里会直接告诉你期望多少实际多少。4.3 VEHX拿自己的飞行模型驱动画面VEHX 是给「我有飞行模型但没有视景」的人准备的。你算好位姿发给模拟器它把这架飞机摆过去渲染。文档里p字段的说明是「用 0 驱动你正在飞的主机来当视景」这句话是重点——填 0 就是接管主视角飞机配合外部飞行模型画面里看到的就是你自己的动力学结果。数据字段只有六个纬度、经度、海拔、真航向、俯仰、滚转。全部是绝对量没有角速度也没有速度分量。这意味着模拟器只负责摆位置速度由它自己按位置差分推。这在低速率下发时会露馅10Hz 发一次模拟器算出来的速度会有明显跳变视景看起来一顿一顿的。常见做法是把发送频率提到 30 到 60Hz或者干脆自己算好速度一并控制。注意VEHX 只改位置和姿态不改飞机状态。如果你接管主飞机之后还想让模拟器自己飞记得停发 VEHX否则两边会打架——你发一包它摆一次它的飞行动力学再改一次画面就抖成了帕金森。4.4 RREF 订阅与 DREF 写入dataref 的两条腿前面那些消息都是「结构化」的覆盖面有限。真正能碰到模拟器内部几千个变量的是 dataref 机制。文档给了两条腿RREF 读DREF 写。RREF 的输入结构是int freq int en char[400]freq是每秒发送次数en是你自己编的一个整数编号作为回包的身份标识。回包结构是int en float val只有 8 字节靠en区分是哪个 dataref 的值。这个编号机制是必须的因为你通常会同时订阅几十个变量回包全靠它路由。DREF_IN struct.Struct(ii400s) # 4 4 400 408 def build_rref(freq: int, dref_id: int, path: str) - bytes: 订阅一个 datarefpath 必须是空值终止的字符串 assert len(path) 400 payload DREF_IN.pack(freq, dref_id, path.encode(ascii)) return bRREF\x00 payload400s会自动把不足 400 字节的部分补零正好满足空值终止的要求不用手动加\0。freq填 0 就是退订这是文档里唯一一句关于停止推送的说明很容易漏。DREF 是写结构是float var char[500]总共 504 字节加上 5 字节前言正好 509——文档里那句「完成整个消息到 509 字节」说的就是这个数。写入时有个细节路径结束后要补零填满整个 500 字节空间不能只发到字符串结束就收工。DREF_OUT struct.Struct(f500s) # 4 500 504 def build_dref(path: str, value: float) - bytes: 把任意 dataref 设成指定浮点值 payload DREF_OUT.pack(value, path.encode(ascii)) return bDREF\x00 payload用这个机制加上 dataref 路径理论上能碰到模拟器里任何一个浮点变量。文档提到 dataref 列表可以去社区站点查那是这个生态里最有价值的公共资源之一。4.5 CMND / SIMO / DATA / DSEL剩下的四把遥控器还有四条消息构成外围能力CMND最简单数据区就是一个字符串命令直接触发模拟器里的某个操作。命令字符串的格式是「组名 / 命令名」比如sim/flight_controls/flaps_up收襟翼。去哪里找完整命令表文档给了个很聪明的办法——打开模拟器的按键设置界面切到高级标签屏幕上显示的组名加右侧的命令串拼起来就是可用的 CMND 字符串。这个方法比翻文档快得多。SIMO负责场景和电影的存读结构是int type char path[]四个枚举值分别对应存场景、读场景、存电影、读电影。做回放或者批量测试的时候用得上。DATA是批量控制数据输出变量的手段结构是int index float[8]。index对应数据输出列表里的序号后面八个 float 是那一项对应的数值。填 -999 表示「不要控制这一项交还给模拟器默认」。这是用来接管操纵杆偏转、无线电频率这类量的适合自制硬件外设。DSEL / USEL / DCOC / UCOC是四个成对的开关控制哪些数据输出项要往外发。DSEL 后面跟一串整数表示要选中的数据输出项序号从 1 开始后面三个分别是取消选择、选中座舱显示、取消座舱显示。文档那句DSEL0456的例子容易看岔——它不是把 0、4、5、6 当四个序号而是标签DSEL后面紧跟的整数序列具体边界以你实际发的字节为准建议在代码里显式构造而不是靠字符串拼接。5. 避坑与常见问题五条血泪记录这套协议没有错误码没有重传出问题全靠日志和猜。下面五条是我在实际项目里踩过的按现象、原因、解决三段写。5.1 包发出去了模拟器毫无反应现象socket 的sendto返回了正常字节数但订阅的通道一个包都不回日志里也没有明显报错。原因结构体对齐算错包的实际长度和模拟器期望的长度不一致它直接丢弃。最常见的触发点是int后面跟double或者字符数组后面跟int。解决打开模拟器设置里「操作与警告」页面的网络数据转储开关它会把你发的东西和期望的结构大小一起写进日志文件。跑一次比对两个数字差几字节就补几字节。补完再跑一次数字对上了基本就通了。5.2 第一包能收到后面就断了现象RPOS 订阅后能收到一两个包然后静默。原因客户端没有 bind 固定源端口或者 bind 之后没保持 socket 打开。协议规定回包发回你发送命令时的源 IP 和端口端口一换包就进了黑洞。解决客户端启动时绑定一个固定端口整个生命周期内复用同一个 socket。如果是多通道并发可以在同一个 socket 上收所有回包靠 5 字节前言区分类型不必开多个端口。5.3 解出来的数值全是天文数字或者 NaN现象位置数据解析出来经度几千、纬度几万或者干脆是 NaN。原因忘了跳过前 5 字节前言直接拿标签的 ASCII 码去解 double。R是 0x52P是 0x50拼起来的字节序列当浮点解释就是个离谱的值。解决所有回包解析前先判断data.startswith(bTAG)然后统一用data[5:]取数据区。这一步最好封装进一个公共函数避免每个消息类型各写一遍、各忘一遍。5.4 DREF 写了但模拟器里的开关不动现象按 509 字节发的写入包长度对齐都对变量就是不变。原因两个可能。一是路径字符串没填满 500 字节的剩余空间尾部残留了上一包的脏数据二是这个 dataref 是只读的文档明确说了「不是所有变量都能设置比如马赫数由飞机速度决定」。解决打包时用定长字符数组类型Python 里的500s、C 里的memset后strncpy让剩余字节自动归零。对于只读变量先试试 RREF 能不能读到读得到但写不进去基本就是只读换一个可写的等价变量。5.5 高频发送把模拟器拖卡现象把 RPOS 频率提到 100Hz、又同时开 RADR 和 FLIR模拟器帧率明显下降操作开始发黏。原因文档提前警告过——网络数据转储开关本身就会让模拟器变慢开发期开着是权宜之计。另外每条推送通道都在模拟器主循环里占时间通道越多、频率越高占用越大。解决转储开关只在排查时开平时关掉。推送频率按实际需求调姿态类 30 到 60Hz 足够气象雷达 5 到 10Hz 就够肉眼看了。图像类通道单独走一个 socket别和实时性要求高的位置通道挤在一起。6. 二次开发把散落的消息收成一套客户端把这份文档用起来的方式不是照着消息列表一条条写 if-else而是先抽象出一层薄薄的客户端。我的做法是三个类打底一个PacketCodec管拼包解包和对齐一个Subscriber管订阅生命周期和超时重订一个Channel按消息类型注册回调。这样后面加一个新消息只需要写一对 encode/decode 函数其余全复用。具体落地时对齐这块我建议按消息类型分别声明格式串并在模块加载时用calcsize做一次自检把每个结构的字节数打印出来对照文档消息方向结构大小校验点RPOS出5 64无填充紧凑即可RADR出5 16×NN 由回包长度反推VEHX入5 48两处 4 字节填充RREF入5 408字符数组自动补零DREF入509定长 500 字节路径DATA入5 36无填充验证方法我习惯分三层走。第一层是单元测试把已知字节流喂给 decode 函数比对字段值第二层是回环测试起一个假的 UDP 服务端把你的包原样吐回来验证收发对称第三层才是接真模拟器先只开一条 RPOS 通道看数据流稳不稳再逐条加。跳过前两层直接上真机出了问题你根本分不清是协议错还是业务错。改造的时候有个思路值得试把这套 UDP 客户端做成一个本地网关对外暴露 WebSocket 或串口。这样上位机界面、单片机外设、移动端都能接同一份数据不用每端各写一套 socket 代码。我自己那套里就是网关进程订阅 RPOS 和一批 RREF再按需分发给三个下游改一个字段只需要动网关一处。还有一个容易被忽略的细节退订。很多客户端跑起来就不管了退出时直接杀进程模拟器那边还留着订阅记录继续往一个死端口发包时间长了会积压。正常退出时给每条订阅发一次freq 0的 RREF或者干脆重启模拟器是更干净的做法。从那以后我每次写完订阅逻辑都强制走一遍「开通道、跑十分钟、主动退订、看日志确认不再发包」的流程宁可多花十分钟也不要留下一个只在长跑时才炸的隐患。这份文档本身已经把消息清单和结构定义给全了剩下的就是把这堆裸包封成自己能维护的代码。需要这份中文说明的话按文中的消息类型和结构体对照着读一遍再拿我上面那段 RPOS 骨架跑通第一条回路后面的事情就顺了。希望帮到你。本文还有配套的精品资源点击获取