简介：《X-Plane11_UDP通信的说明文档（中文）》面向飞行模拟器开发者、虚拟座舱与运动平台搭建者，以及需要通过外部程序读写飞行数据的爱好者，系统梳理 X-Plane 11 基于 UDP 与外部应用交互的机制。文档围绕端口 49000 的收发规则、字符串空值终止、消息类型与数据格式展开，既说明 RPOS 等输出请求如何驱动自建视景或移动地图，也列出 ACFN、PREL、ACPR 等飞机加载定位消息，并提示利用“转储网络数据到 log.txt”排查通信错误。压缩包共 1 个 docx 文件，约 44KB，篇幅精炼，适合作为协议速查与联调参考。已有 2063 人学习，读者可据此理解插件与 UDP 两条实现路径的取舍，掌握驾驶 X-Plane 或聆听其数据的典型用法，并快速定位消息字段与常见注意事项，减少从零摸索协议的成本。
1. 一份 49000 端口上的中文 UDP 手册，能省掉多少试错
第一次给自建座舱写驱动的人，八成都会在同一个地方卡住：X-Plane 11 明明在跑，飞机也在动，可自己写的程序发出去的包像扔进了黑洞，既没有回应，也没有报错。问题往往不在代码逻辑，而在没人告诉你那 5 个字节的序言该怎么拼、结构体在 Intel 64 位下会插几个填充字节、字符串忘了补 0 会怎样。这份 X-Plane 11 UDP 通信中文说明文档，干的就是把散落在论坛帖、英文注释和试错记录里的东西收拢成一份能对着抄的规格：端口固定 49000，4 字符标签加一个 0 字节开头，后面跟紧打包的数据体，从 V10 迁到 V11 时哪些标签被改名、哪些被砍掉，也都写在里面。适合做座舱硬件、运动平台、外部视景、飞行数据采集的人，读完至少能少熬两个通宵。
2. 消息帧与结构体对齐：5 字节序言和 8 字节边界的两个死结
2.1 一条消息的骨架只有三段
不管你是想读位置还是想改开关，X-Plane 的 UDP 报文在字节层面永远是同一副骨架：4 个 ASCII 字符的消息标签、1 个值为 0 的字节、然后是数据体。那个 0 字节不是为了占位好看，它的作用是给标签做空值终止，让接收端用最朴素的方式就能切出标签。文档里反复强调的「任何字符串都应该以空值终止」，指的就是这个习惯要从标签一路贯穿到数据体里的每一个路径字符串。
举个最小的例子，让 X-Plane 每秒回传 60 次飞机位置，你要发的东西是标签RPOS、一个 0 字节、字符串60、再一个 0 字节。注意频率是用字符串传的，不是二进制整数。这个设计看着别扭，实际很聪明：字符串没有字节序问题，你在任何语言、任何架构上拼出来都一样，省掉了一整类「我发的是 60，它收到的是 1006632960」的血泪经验。
import socket SIM_IP = "127.0.0.1" SIM_PORT = 49000 # X-Plane 固定在这个端口收包，文档里写死，不可改 LISTEN_PORT = 49001 # 自己监听的端口，X-Plane 会把回传发到这里 def build_simple(label: str, arg: str) -> bytes: """构造 标签 + 0x00 + 参数字符串 + 0x00 的简单报文""" assert len(label) == 4, "标签必须是 4 个 ASCII 字符" return label.encode("ascii") + b"\x00" + arg.encode("ascii") + b"\x00" sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind(("0.0.0.0", LISTEN_PORT)) # 先绑定，再发请求，否则回传会丢 pkt = build_simple("RPOS", "60") sock.sendto(pkt, (SIM_IP, SIM_PORT)) print("发送", len(pkt), "字节:", pkt)这段代码里有两处值得单独说。第一，sock.bind必须放在sendto之前。X-Plane 会把回传数据发回「你发请求时用的那个 IP 和端口」，文档里对 RPOS、RADR、RREF 都明确写了这一点。如果你用的是一个临时端口发出去、再另开一个 socket 收，那基本收不到东西，这不是玄学，是协议本身这么定的。第二，label长度断言别省，RPOS写成Rpos或RPOSS都会安静地失败，服务端不会给你任何提示。
2.2 结构体对齐：Intel 64 位下的 4 字节与 8 字节边界
真正让新手翻车的是数据体。文档里那一段关于字节对齐的说明写得比较绕，翻译成人话是：X-Plane 内部用的结构体是按 Intel 64 位平台的编译器规则排布的，int和float对齐到 4 字节边界，double对齐到 8 字节边界。编译器为了让每个成员落在它该在的偏移上，会自动往中间塞填充字节，而这些填充字节你必须在自己的报文里一模一样地补出来。
最典型的例子是 VEHX，也就是「用我自己的飞行模型驱动 X-Plane 当视景器」那条消息。它的结构体长这样：
struct vehx_struct { int p; // 要控制的飞机索引，0 是主飞机 double dat_lat; // 纬度，度 double dat_lon; // 经度，度 double dat_ele; // 海拔，米 float veh_psi_true; // 真航向，度 float veh_the; // 俯仰，度 float veh_phi; // 滚转，度 };肉眼看过去是 4 + 8 + 8 + 8 + 4 + 4 + 4 = 40 字节，实际编译出来是 44 字节。因为int p只占 4 字节，紧跟着的double dat_lat要求起始偏移是 8 的倍数，编译器就在中间塞了 4 个字节的填充。你要是按 40 字节手工拼包发过去，X-Plane 解出来的纬度会是天文数字，飞机瞬间飞到宇宙边缘，然后你可能还会以为是坐标系搞错了。
Python 的struct模块默认用小端紧凑模式，不加任何填充，所以填充得自己写：
import struct # "<" 小端，"i" int32，"4x" 四个填充字节，"d" double，"f" float VEHX_FMT = "<i4xdddfff" print("VEHX 数据体大小:", struct.calcsize(VEHX_FMT)) # 44 def build_vehx(idx, lat, lon, ele, psi, the, phi): body = struct.pack(VEHX_FMT, idx, lat, lon, ele, psi, the, phi) return b"VEHX\x00" + body pkt = build_vehx(0, 39.9042, 116.4074, 1200.0, 90.0, 2.5, -1.0) print("整包大小:", len(pkt)) # 5 + 44 = 494x就是那 4 个填充字节，写的时候不起眼，漏了就是整包作废。文档里还有一句容易被跳过的细节：如果结构体里有数组，比如xchr path[150]，编译器只会把数组的第一个元素推到对齐边界上，数组内部每个元素仍然紧凑排列，后面的成员接着往下排。所以acfn_struct（4 字节 int + 150 字节字符数组 + 4 字节 int）实际是 4 + 150 + 2 字节填充 + 4 = 160 字节，那个 2 字节填充是因为 154 不是 4 的倍数。这种地方没有捷径，只能一个个算，或者用下一节的办法让 X-Plane 自己告诉你。
2.3 一个能复用的打包与收包封装
实际项目里我不会每发一条消息就手写一遍sendto，而是抽一个薄封装，把「拼标签、补填充、记录字节数、设超时」这几件事固化下来。字节数打印这个习惯看着土，但它是排查对齐问题最快的手段：日志里显示发出去 49 字节、X-Plane 期望 44 字节，问题基本就锁定在填充上了。
import socket, struct, time class SimLink: def __init__(self, sim_ip="127.0.0.1", sim_port=49000, listen_port=49001): self.addr = (sim_ip, sim_port) self.sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) self.sock.bind(("0.0.0.0", listen_port)) self.sock.settimeout(2.0) # 收不到就抛异常，别死等 def send(self, label: str, body: bytes): pkt = label.encode("ascii") + b"\x00" + body self.sock.sendto(pkt, self.addr) return len(pkt) def recv(self): data, _ = self.sock.recvfrom(8192) return data[:4].decode("ascii", "replace"), data[5:]recvfrom的缓冲区给了 8192 字节，因为 FLIR 图像那类回传包远比位置包大，缓冲区给小了会被截断，而 UDP 截断是静默的，你只会看到解包时报「数据不足」。settimeout也别省，没有超时的 UDP 接收会把整个程序卡在第一帧，调试阶段非常耽误事。
3. 读取侧三条回传通道：RPOS 位置、RADR 雷达与 RREF 数据引用
3.1 RPOS：69 字节的位置流
RPOS 是这份文档里最实用的一条输出。发一次请求，X-Plane 就按你给的频率持续往回推位置、姿态、速度和角速度，做移动地图、外部视景、运动平台都靠它。整包 69 字节：5 字节序言，3 个 double 共 24 字节，10 个 float 共 40 字节。
RPOS_FMT = "<5sddd10f" # 5s 把标签和 0 字节一起吃掉 assert struct.calcsize(RPOS_FMT) == 69 NAMES = ["lon", "lat", "ele_m", "agl_m", "pitch", "heading", "roll", "vx_east", "vy_up", "vz_south", "P_rad", "Q_rad", "R_rad"] def parse_rpos(data: bytes): vals = struct.unpack(RPOS_FMT, data) return dict(zip(NAMES, vals[1:])) link = SimLink() link.send("RPOS", b"60\x00") # 每秒 60 次 for _ in range(5): label, body = link.recv() if label == "RPOS": print(parse_rpos(b"RPOS\x00" + body))字段含义和单位要对齐文档里的定义，别凭感觉：lon/lat是度，ele_m是海平面以上的米数，agl_m是离地高度米数，pitch/heading/roll是度，三个速度分量是按「x 向东、y 向上、z 向南」定义的，单位米每秒，最后三个是角速度，单位弧度每秒。这里最容易踩的坑是把pitch和heading的顺序记反，或者把角速度当成角度直接用。我一般会在第一次接入时把heading打印出来，手动在模拟器里转一圈机头，看数值是不是跟着从 0 走到 360，验证一次比读十遍文档管用。
频率参数给多少合适，取决于你的下游。驱动一块 60Hz 的视景屏就给 60，做数据记录 10 到 20 就够。给太高的直接后果是网络线程和模拟器主循环抢时间，帧率肉眼可见地掉。
3.2 RREF：按名字订阅任意数据引用
RPOS 只覆盖位置这一类。想读发动机转速、襟翼角度、起落架状态、油量，就得用 RREF。它的请求结构体是三个成员：频率、一个你自编的整数编号、以及最长 400 字节的数据引用路径字符串。响应结构体只有两个成员：那个编号，和一个 float 值。
编号dref_en是整个机制的关键。你可能会同时订阅几十个 dataref，回传的包本身不带名字，只带你当初给的那个整数，所以你得在本地维护一张编号到路径的映射表。这是典型的用空间换解析成本的做法，实现简单，但在订阅数量多的时候一定要保证编号唯一，重复了就会串数据。
RREF_IN_FMT = "<ii400s" # freq, en, path[400] RREF_OUT_FMT = "<if" # en, value def subscribe(link, path: str, en: int, freq: int = 10): body = struct.pack(RREF_IN_FMT, freq, en, path.encode("ascii")) return link.send("RREF", body) def parse_rref(body: bytes): en, val = struct.unpack(RREF_OUT_FMT, body) return en, val registry = {} subscribe(link, "sim/flightmodel/engine/POINT_thrust[1]", 1001, 20) registry[1001] = "engine1_thrust" while True: label, body = link.recv() if label == "RREF": en, val = parse_rref(body) print(registry.get(en, en), val)三个参数各有讲究。freq是每秒回传次数，设成 0 就是退订，这在切换机型或者关闭某个面板时一定要记得发，否则那些订阅会一直挂着吃带宽。en建议按功能分段，1000 段给发动机、2000 段给航电，出问题时一眼能看出是哪一块。路径里的数组索引用方括号加数字，文档特别提醒了索引从 0 开始，POINT_thrust[1]是第二台发动机，写[0]才是第一台。
响应里的值永远是 float，哪怕这个 dataref 在模拟器内部是个整数或者布尔。文档里写得很直白：dref_flt是机器本机浮点值，即使是整数也一样。所以判断开关状态时用大于 0.5 这类阈值比较，别拿它跟 1 做相等判断。
3.3 RADR 与 FLIR：雷达回波与图像帧
RADR 用来拿天气雷达的回波点，做自己的气象显示。请求格式和 RPOS 一样是「标签 + 0 + 频率字符串 + 0」，只不过这里的频率含义是每帧回传多少个雷达点。响应是每个点四个 float，紧凑排列，没有结构体对齐的麻烦事。
| 字段 | 类型 | 含义 |
|---|---|---|
| lon | float | 雷达点经度，度 |
| lat | float | 雷达点纬度，度 |
| storm_level_0_100 | float | 降水强度，0 到 100 |
| storm_height_meters | float | 风暴顶高，海平面以上米数 |
RADR_PT_FMT = "<4f" RADR_PT_SIZE = struct.calcsize(RADR_PT_FMT) # 16 def parse_radr(body: bytes): n = len(body) // RADR_PT_SIZE pts = [] for i in range(n): lon, lat, lvl, top = struct.unpack_from(RADR_PT_FMT, body, i * RADR_PT_SIZE) pts.append((lon, lat, lvl, top)) return ptsparse_radr里用「总长度除以单点长度」来推算点数，而不是把点数写死成 10。因为你请求时给的是每帧点数，实际回传可能因为回波不足而少于这个数，写死会解出垃圾数据。
FLIR 那条通道回传的是图像帧，频率含义是每秒多少帧，文档里把完整的图像提取代码单独放在另一份文件里，说明它的数据体比位置包复杂得多。如果你的目标只是驱动仪表和视景，RPOS 加 RREF 已经覆盖九成需求，FLIR 属于另一个量级的工程。
4. 写入侧四把工具：DREF 改值、CMND 触发命令、DATA 接管轴量与 VEHX 外部驱动
4.1 DREF：509 字节的定长写入
DREF 是把任意一个 dataref 写成指定浮点值的通道。它的结构体是 4 字节 float 加 500 字节路径，加上 5 字节序言，整条消息正好 509 字节，文档里把这个数字写死了，这是个非常好的自检点：你的包不是 509 字节，就一定有问题。
DREF_FMT = "<f500s" assert struct.calcsize(DREF_FMT) + 5 == 509 def set_dref(link, path: str, value: float): raw = path.encode("ascii") assert len(raw) < 500 body = struct.pack(DREF_FMT, value, raw) # 500s 会自动补 0 到 500 字节 return link.send("DREF", body)500s这个格式符会自动在字符串后面补 0，直到占满 500 字节，这正是文档要求的「NULL 终止 + 补空白」。整个包也因此固定 509 字节，不用你手动数空格。文档里举的例子是开防冰开关，值为 1，路径写sim/cockpit/switches/anti_ice_surf_heat_left，逻辑是一样的。
有个边界要说清楚：DREF 只能写浮点。有些 dataref 在模拟器内部是整数枚举或者只读的，写进去要么被忽略，要么立刻被模拟器覆盖回去。文档自己也提示了「有些消息会被 X-Plane 覆盖」，马赫数这种由速度推导出来的量就是典型。判断一个 dataref 能不能写，最省事的办法是先在数据输出界面里找到它，看它是否可编辑。
4.2 CMND：用字符串按一次按钮
CMND 的数据体就是一个字符串，内容是你在「设置 - 操纵杆和设备 - 按钮：高级」里看到的那串命令名，比如收襟翼那条。这条通道的好处是不需要知道任何 dataref 路径，模拟器里能用按钮触发的事情，它基本都能触发。
def send_command(link, cmd: str): # CMND + 0x00 + 命令字符串 + 0x00 return link.send("CMND", cmd.encode("ascii") + b"\x00")命令字符串从哪里抄？打开那个高级按钮页面，屏幕上显示的分组名加上右侧的命令串，拼起来就是完整命令。抄的时候注意大小写和下划线，这东西不像 dataref 有容错，错一个字符就是没反应。CMND 没有回执，所以排查时要靠模拟器里的实际动作来判断，别指望日志给你提示。
4.3 DATA 与 DSEL：按索引接管轴量与批量订阅
DATA 走的是「数据输出索引」这条路。它的结构体是一个 int 索引加 8 个 float，对应数据输出界面里那一行最多 8 个数字。用它可以把摇杆偏转、舵量这类连续量塞进模拟器，等于用你自己的硬件飞飞机。
DATA_FMT = "<i8f" assert struct.calcsize(DATA_FMT) == 36 def send_data(link, index: int, values): vals = list(values) + [0.0] * (8 - len(values)) body = struct.pack(DATA_FMT, index, *vals) return link.send("DATA", body) def release_data(link, index: int): send_data(link, index, [-999.0]) # -999 表示交还控制权索引从哪来？就是数据输出界面里变量的排列顺序。-999这个值是文档里给的「后悔药」，把它发过去表示这一项不再由 UDP 控制，交回模拟器默认逻辑。调试阶段这个功能非常关键：一旦你的程序崩了没发-999，而接管还在生效，飞机就会保持在你最后一次发出去的杆量上，表现为「模拟器不受控制」，很容易误判成模拟器出问题。
DSEL、USEL、DCOC、UCOC 这一组则是批量订阅和退订数据输出项。数据体是一串 int，代表数据输出列表里的序号，第一个是 1，第二个是 2。文档里那个DSEL0456的例子意思是让第四、五、六项按设置里配置的地址往外发。这四个标签适合做固定面板的批量数据采集，写一次就不用再管，缺点是粒度粗，改一项要重发整串。
4.4 VEHX：把 X-Plane 降级成纯视景器
如果你的飞行动力学是自己在外面算的，只想让 X-Plane 负责渲染画面，VEHX 就是那个入口。它的结构体在第 2 章已经拆过，这里说用法上的三个要点。
第一，p参数用 0 表示驱动你正在飞的那架主飞机，1 到 19 是其他飞机。做外部视景时几乎总是 0。第二，纬度经度是 double，精度足够，别为了省字节改成 float，尤其在做长距离飞行时误差会累积。第三，发送频率要跟你的动力学步长对齐，你的模型跑 50Hz，就老老实实每 20 毫秒发一次，不要攒批也不要超频，否则画面会一顿一顿的。
VEHX_FMT = "<i4xdddfff" def drive_visual(link, lat, lon, ele, psi, pitch, roll, idx=0): body = struct.pack(VEHX_FMT, idx, lat, lon, ele, psi, pitch, roll) link.send("VEHX", body)姿态角的定义要和文档一致：veh_psi_true是真航向，veh_the是俯仰，veh_phi是滚转，单位都是度。如果你的模型内部用弧度或者四元数，转换要在发送前做完，别指望模拟器猜。多架飞机同时驱动时，每条 VEHX 只带一个索引，所以是每条消息一架飞机，不是一次发一堆。
5. 排查：五条让 UDP 消息石沉大海的现场记录
5.1 现象：日志里报的结构体尺寸和我算的对不上
原因几乎总是填充字节算漏了，尤其是「int 后面直接跟 double」这种组合。我见过一次是把 PREL 结构体的字段顺序按文档抄了，但漏掉了两个 int 之后到第一个 double 之间的对齐填充，结果 X-Plane 收到的字段整体错位，飞机被定位到了南半球。
解决方式是打开「设置 - 操作和警告」里的「转储网络数据到 log.txt」开关，把数据转到error.out。这个开关会让模拟器稍微变慢，所以只在排查时开，跑通了立刻关掉。打开后你发的每一条消息，X-Plane 都会在日志里记下它期望的字节数和实际收到的字节数，两个数字一对比，差几个字节一目了然。补填充、重发、再看日志，这个循环比盲猜快得多。
5.2 现象：请求发出去了，回传一条都收不到
原因通常有两个。一是收包的 socket 和发包的 socket 不是同一个端口，而 X-Plane 明确会把回传发回「你发命令时用的那个 IP 和端口」。二是防火墙拦了入站 UDP，出站正常所以发送不报错，你会误以为一切正常。
解决办法是先确认bind的端口和发送源端口一致，然后把回传的recvfrom加上超时并打印来源地址，看看究竟有没有包进来。如果来源地址一直不出现，用本机回环地址先测一遍，排除网络设备因素，再往外网环境迁移。
5.3 现象：一开高频订阅，模拟器帧率就往下掉
原因是你把 UDP 输出频率设得比下游需要的还高，或者订了一堆根本用不上的 dataref。文档里对「转储网络数据」那句提醒同样适用于输出：输出本身是有成本的，40 个 dataref 全开 60Hz，每秒就是两千多个包。
解决办法是按需分层：姿态和位置走 RPOS 一路流，仪表类走 RREF 但频率压到 5 到 10Hz，只在面板打开时才订阅，关掉立刻发freq = 0退订。我一般的做法是给每个面板维护一个订阅集合，面板隐藏时整批退订，这个习惯能省掉大量无谓流量。
5.4 现象：包长度完全正确，但整包被丢弃
原因是数据体里的字符串没有空值终止，或者长度刚好占满数组没留结尾的 0。文档里那句「您发送的任何字符串都应该以空值终止」不是客套话，从标签到路径到命令串，全都要遵守。
解决办法是把断言写进代码里：字符串编码后的长度必须小于数组容量，打包时用500s这种定长格式符让它自动补 0，而不是用500c或者手动拼。发之前打印一下整包长度，509、413、49 这几个数字很好记，对上了基本就不会错。
5.5 现象：V10 时代能用的标签，换到 V11 没反应
原因是从 V10 到 V11 有一批消息被改名或直接砍掉了。如果你的代码是从旧项目搬过来的，这部分必须逐个替换，模拟器不会为旧标签做兼容。下面是文档里给出的对照关系：
| 用途 | V10 旧标签 | V11 的处理 |
|---|---|---|
| 按机场定位飞机 | PAPT | 用 PREL，走机场 ID 分支 |
| 机场附近定位 | PMAP | 用 PREL |
| 移动单架飞机 | VEH1 | 用 VEHX |
| 移动所有飞机 | VEHA | 用 VEHX |
| 选择菜单 | MENU | 用 CMND |
| 字符输入 | CHAR | 用 CMND |
| 鼠标操作 | MOUS | 用 CMND |
| 互联网输出开关 | ISET | 用 ISE4 |
| 加载飞机 | ACFN（无涂装字段） | ACFN，结构体增加涂装索引 |
| 炸毁飞机 | HACF | 已废弃 |
| 快速播放动画 | R_QT | 已废弃 |
替换时注意 ACFN 不是简单改名，是结构体变长了：多了livery_index字段，而且因为 150 字节的字符数组后面接了 int，中间会有 2 字节填充。按老结构体发过去，长度对不上，直接失败。至于被标为废弃的 HACF 和 R_QT，没有等价替代，涉及这两条的功能要重新设计实现方式。
6. 最小验证闭环：三分钟确认这条链路真的通了
接手任何一套 sim 接口，我的习惯是先跑一个「读一次、写一次、再读回来对账」的闭环，再动业务代码。X-Plane 这套 UDP 接口尤其适合这么干，因为 RPOS 既能读位置，VEHX 又能写位置，天然构成闭环。
具体做法是：先用 RPOS 以 10Hz 订阅位置，收到第一帧后记下当前经纬高；然后用 VEHX 把飞机沿纬度方向挪一个小量，比如加 0.01 度；继续收 RPOS，看重放出来的纬度是不是跟着动了。如果数值变了，说明发送链路和回传链路都是通的，后面再怎么加复杂度都有底。
import time, struct link = SimLink() link.send("RPOS", b"10\x00") first = None deadline = time.time() + 3 while time.time() < deadline and first is None: label, body = link.recv() if label == "RPOS": first = parse_rpos(b"RPOS\x00" + body) print("基准点:", first["lat"], first["lon"], first["ele_m"]) # 沿线挪 0.01 度，保持高度和姿态不变 drive_visual(link, first["lat"] + 0.01, first["lon"], first["ele_m"], first["heading"], 0.0, 0.0) for _ in range(20): label, body = link.recv() if label == "RPOS": now = parse_rpos(b"RPOS\x00" + body) print("回读纬度:", now["lat"]) break这段脚本里有两个容易忽略的细节。一是挪动量别贪大，0.01 度大约是 1 公里量级，足够被观测到又不会触发模拟器的异常状态。二是姿态角要原样回传，如果你随手填 0，飞机会被强行掰平，回读的位置虽然变了，但你不能确定是位移生效还是姿态重置带来的副作用，验证就不干净了。
对账这一步的意义在于把「有没有通」和「对不对」分开。通信通不通看字节数和日志，数值对不对看这个闭环。我见过太多情况是包发出去了、日志里长度也对，但字段顺序抄错，位置看着在动，实际是经纬度写反了，飞机在地图上横着飘。闭环跑一次，这类问题当场现形。
从那以后我每次接一个新的仿真接口，都强制先走一遍「发一条、收一条、对数」这三步，再写任何业务逻辑。这份文档的价值也在这儿：它把每条消息的字节布局和迁移关系都摊开了，你不用再从报错里反推。希望帮到你。
本文还有配套的精品资源，点击获取
