企业官网建设流程全解析

简介：本资源是一套基于C#开发的三菱FX5U PLC上位机以太网通信实战项目，面向工业自动化领域初/中级开发者、控制系统集成工程师及自动化立体仓库系统设计人员，解决PLC与上位机间通过3E帧协议实现高速稳定通信的核心问题。压缩包共35个文件，含10个核心C#源码文件（.cs）、3个可执行程序（.exe）、1个Visual Studio解决方案（.sln）及配套配置（.config）、资源（.resx/.resources）和调试支持文件（.pdb/.suo），完整覆盖WinForm界面开发、RawSocket底层报文构造、3E帧解析与错误重试机制等关键模块，包体仅79KB，轻量易部署。已有466人学习下载。读者可直接运行调试工程，深入理解FX5U私有以太网协议在仓储控制场景中的指令交互逻辑，获取可复用的报文封装类、网络接口筛选策略及状态可视化UI组件，是少有的兼顾协议深度与工程落地性的C#工业通信参考实现。

1. 为什么选 FX5U + C# WinForm 做上位机？不是因为“简单”，而是它真能扛住立体仓库的实时心跳

某高校自动化专业学生做毕设时，最初想用 Python + PyQt 搭个界面，结果在模拟 32 台堆垛机并发读写时，报文丢帧率突然跳到 12%——PLC 端日志显示指令已发出，但上位机收不到 ACK。最后换回 C# WinForm + 原生 Socket 异步通信，配合 FX5U 的 MELSEC Communication Protocol（MC 协议）二进制帧格式，实测 50ms 周期下连续 72 小时无丢包。这不是怀旧，是工程选择：WinForm 的 UI 线程隔离性、.NET 对 TCP 粘包/半包的可控处理能力、以及 FX5U 对 MC 协议的原生硬件级支持，三者叠加才撑得起立体仓库里“指令下发→状态回传→异常重试→日志落盘”这一整条数据链路。本方案面向的是需要交付可运行、可答辩、可现场演示的课设/毕设同学，也适用于小型自动化集成商快速搭建调试工具——它不追求炫酷动效，但每一条报文都带校验、每一次连接都可监控、每一个地址读写都可追溯。核心就一句话：用最稳的栈，干最糙但最不能出错的活。

2. 总体架构设计：三层结构与四个核心模块的职责划分

本方案采用清晰的三层架构：通信驱动层 → 数据服务层 → 业务逻辑层，完全解耦，方便调试与替换。其中通信驱动层直接对接 FX5U 的以太网端口（默认端口 6000），不依赖 GX Works2 或第三方 OPC Server；数据服务层负责地址映射、报文组装/解析、超时重试与缓存；业务逻辑层则聚焦于立体仓库特有的动作编排，如“入库任务拆解为巷道→货位→升降→伸缩四步序列”。整个系统由四个不可删减的核心模块构成：MC协议解析器、PLC连接管理器、地址映射配置中心、实时监控面板。它们不是并列关系，而是有明确调用链：用户在监控面板点击“读取W100”，触发地址映射中心查出该地址对应物理寄存器类型（如 D1000），再交由 MC 协议解析器生成 0x50 帧头+地址偏移+字节数的二进制请求，最后由连接管理器发往 PLC 并等待响应。这种设计让每个模块只做一件事，出了问题能快速定位到具体环节，而不是在一团线程和回调里抓瞎。

2.1 MC协议解析器：手撕二进制帧，拒绝黑匣子式封装

FX5U 的 MC 协议（QnA 兼容模式）是典型的二进制私有协议，没有 XML 或 JSON 那种可读性，但好处是极轻量、低延迟。本方案不使用任何第三方 MC 协议库（如 NModbus 的变种），而是用 C#Span<byte>手动构造请求帧。关键在于理解帧结构：前 2 字节固定为0x50 0x00（批量读命令），第 3-4 字节为网络号（通常 0x00 0x00），第 5-6 字节为 PLC 号（0x00 0x00），第 7-8 字节为目标模块 I/O 号（0xFF 0xFF 表示本体），第 9-10 字节为请求数据长度（单位：字），后续才是地址数据区。例如读取 D1000 开始的 2 个字（D1000、D1001），地址数据区需填入0x00 0x00 0x03 0xE8 0x00 0x02（03E8 = 1000 十进制，0002 = 2 字）。响应帧同样需手动解析：先校验头 2 字节是否为0x50 0x00，再跳过 10 字节头，从第 11 字节开始读取实际返回数据。

// 构造 D 区批量读请求帧（读 D1000 起 2 字） public static byte[] BuildDReadRequest(int startAddress, int wordCount) { var frame = new byte[16]; // 固定头长 + 地址区 6 字节 frame[0] = 0x50; frame[1] = 0x00; // 命令码 frame[2] = 0x00; frame[3] = 0x00; // 网络号 frame[4] = 0x00; frame[5] = 0x00; // PLC号 frame[6] = 0xFF; frame[7] = 0xFF; // I/O号 frame[8] = (byte)(wordCount >> 8); frame[9] = (byte)(wordCount & 0xFF); // 数据长度（字） // 地址区：D区地址 = 0x000003E8（D1000），类型码 0x0000（D区） BitConverter.GetBytes((ushort)0x0000).CopyTo(frame, 10); // 类型码低位高位 BitConverter.GetBytes((ushort)0x0000).CopyTo(frame, 12); // 保留位（QnA模式固定0） BitConverter.GetBytes((uint)startAddress).CopyTo(frame, 14); // 起始地址（大端序） return frame; }

提示：FX5U 的地址编码规则必须吃透。D 区地址直接填十进制值（如 D1000 填 1000），但 X/Y/M/S 等位元件需转换为“软元件代码+起始号”组合。例如 X000 对应代码0x0000，X010 对应0x000A（10 进制转 16 进制），而地址区第 14-17 字节填的是0x00000000（X000）或0x0000000A（X010）。本方案在地址映射配置中心内置了常用软元件代码表，避免手算出错。

2.2 PLC连接管理器：连接池 + 心跳保活 + 异常熔断

立体仓库场景下，PLC 不可能永远在线。若上位机盲目重连，可能引发网络风暴；若连接后长期空闲，又可能被交换机踢掉。本方案采用“连接池 + 主动心跳 + 熔断阈值”三重机制。连接池仅维护 1 个活跃 Socket 实例（非多连接），所有读写请求排队复用该连接；心跳包每 15 秒发送一次0x50 0x00空请求（不带地址数据），若连续 3 次无响应，则触发熔断：关闭 Socket、清空本地缓存、通知 UI 显示“PLC离线”，并启动指数退避重连（首次 1s，失败后 2s、4s、8s…最大 60s）。关键点在于心跳必须走真实数据通道，不能用 TCP KeepAlive——后者只检测链路层，而 FX5U 在应用层挂死时 KeepAlive 仍会成功。

// 心跳检测逻辑（在独立 Timer 中执行） private void CheckPlcHeartbeat() { if (!_socket.Connected) return; try { var heartbeat = new byte[] { 0x50, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00 }; _socket.Send(heartbeat); // 设置 2 秒超时接收响应 var response = ReceiveBytes(2000); if (response.Length < 10 || response[0] != 0x50 || response[1] != 0x00) throw new Exception("心跳响应格式错误"); _consecutiveFailures = 0; // 重置失败计数 } catch { _consecutiveFailures++; if (_consecutiveFailures >= 3) { Disconnect(); // 熔断 StartReconnectBackoff(); } } }

注意：ReceiveBytes()方法必须实现非阻塞接收，否则心跳检测会被卡住。本方案使用Socket.Poll()判断是否有数据可读，再调用Socket.Receive()，避免线程挂起。同时，所有发送操作均加锁（lock(_sendLock)），防止多线程并发写导致帧错乱——这是 WinForm 多事件触发（如按钮连点）时最常见的翻车点。

2.3 地址映射配置中心：JSON 配置驱动，支持运行时热更新

硬编码地址（如ReadD(1000)）会让后期维护变成噩梦。本方案将所有 PLC 地址映射关系外置为mapping.json文件，结构如下：

{ "Warehouse": { "InboundTask": { "address": "D1000", "type": "D", "length": 10, "desc": "入库任务队列（10个任务）" }, "OutboundTask": { "address": "D1010", "type": "D", "length": 10, "desc": "出库任务队列" }, "StackerStatus": { "address": "D2000", "type": "D", "length": 32, "desc": "32台堆垛机状态字" } }, "Alarm": { "Critical": { "address": "M1000", "type": "M", "length": 1, "desc": "急停报警" } } }

程序启动时加载该文件到内存字典Dictionary<string, PlcAddressInfo>，业务层通过键名（如"Warehouse.InboundTask"）获取地址信息，再交由 MC 解析器处理。更关键的是，配置中心监听文件变更（FileSystemWatcher），一旦 JSON 被修改（如新增一个LampSignal地址），自动重新加载并通知 UI 刷新监控列表——无需重启程序。这极大提升了调试效率，比如现场发现某个指示灯没反应，工程师可直接改 JSON 加一行配置，5 秒内生效。

2.4 实时监控面板：WinForm 自绘控件 + 多线程安全刷新

WinForm 默认控件（如 TextBox、Label）在跨线程更新时会抛异常。本方案采用两种策略：对高频刷新项（如堆垛机实时坐标），使用Control.InvokeRequired+BeginInvoke安全委托；对低频状态项（如任务完成数），使用BindingSource绑定ObservableCollection，由数据源变更自动触发 UI 更新。监控面板核心是一个自定义PlcMonitorPanel控件，重写OnPaint方法，用Graphics.DrawString()直接绘制带颜色的状态块（绿色=运行中，红色=故障，灰色=未连接），避免 ListView 等控件的闪烁和性能损耗。例如显示 32 台堆垛机状态，每台用 20×20 像素方块，32 个方块横向排列，刷新率稳定在 100ms/次，CPU 占用低于 3%。

提示：不要在Timer.Tick事件中直接调用Control.Text = xxx！必须用this.Invoke((MethodInvoker)delegate { label1.Text = value; });。本方案在DataReceiver类中封装了SafeUpdateLabel(Label lbl, string text)方法，内部自动判断线程上下文，学生抄作业时直接调用即可，不用纠结原理。

3. 关键模块实现：报文解析、地址读写、任务调度与日志记录

本章聚焦四个最易出错、也最体现工程能力的落地细节。它们不是孤立功能，而是环环相扣的数据流：报文解析正确 → 地址读写可靠 → 任务调度有序 → 日志记录可溯。任何一个环节松动，立体仓库的“自动”二字就成空谈。这里不讲理论，只给能粘贴进 VS 直接跑通的代码片段，并说明每一行为什么这么写、不这么写会怎样。

3.1 报文解析器：如何从 1000 字节响应帧中精准抠出 2 个字的数据？

FX5U 的响应帧包含冗余头信息，且不同命令返回结构不同。以 D 区读取为例，响应帧前 10 字节为固定头（含错误码），第 11 字节起才是有效数据，但数据前还有 2 字节“数据长度”字段（单位：字）。很多初学者直接从第 11 字节开始读，结果读到的是长度值而非真实数据。正确做法是：先读第 11-12 字节得到dataLength（大端序），再从第 13 字节开始读取dataLength * 2字节（因 1 字 = 2 字节）。本方案解析器强制校验响应帧长度：若frame.Length < 13 + dataLength * 2，立即抛异常，避免后续解析越界。

// 解析 D 区读响应帧（输入：完整响应字节数组） public static ushort[] ParseDReadResponse(byte[] response) { if (response.Length < 13) throw new InvalidDataException($"响应帧过短，长度{response.Length} < 13"); // 校验头 if (response[0] != 0x50 || response[1] != 0x00) throw new InvalidDataException("响应帧头错误，非MC协议响应"); // 读取错误码（第 10 字节，0x00 表示成功） if (response[9] != 0x00) throw new InvalidOperationException($"PLC返回错误码：0x{response[9]:X2}"); // 读取数据长度（第 11-12 字节，大端序） int dataLength = (response[10] << 8) | response[11]; // 计算数据起始位置（第 13 字节） int dataStart = 12; int expectedMinLength = dataStart + dataLength * 2; if (response.Length < expectedMinLength) throw new InvalidDataException($"响应帧数据区缺失，期望{expectedMinLength}字节，实际{response.Length}"); // 提取数据（每2字节为1个ushort） var values = new ushort[dataLength]; for (int i = 0; i < dataLength; i++) { int offset = dataStart + i * 2; values[i] = (ushort)((response[offset] << 8) | response[offset + 1]); } return values; }

注意：response[9]是错误码位置，不是第 10 字节索引！数组索引从 0 开始，所以第 10 字节是response[9]。这个细节在调试时救过无数人——当 PLC 地址写错（如 D9999 超出范围），FX5U 会返回错误码0x03，但若没检查这一字节，程序会继续解析垃圾数据，导致 UI 显示乱码数字，排查难度陡增。

3.2 地址读写服务：同步阻塞 vs 异步非阻塞，为什么这里选前者？

网上教程常鼓吹“用 async/await 提升性能”，但在 FX5U 通信中，这是典型误用。原因有三：第一，MC 协议是严格请求-响应模型，无法并行；第二，PLC 处理能力有限，同时发 10 个请求只会让队列更长；第三，WinForm UI 线程本身是单线程，async 后续回调仍需切回 UI 线程更新，反而增加调度开销。本方案所有读写操作均采用同步阻塞 + 超时控制：Socket.Send()和Socket.Receive()均设置SendTimeout和ReceiveTimeout为 3000ms，超时即抛异常，由上层捕获并重试。这样逻辑线性、状态清晰，调试时一眼看出卡在哪一步。

// 同步读取 D 区（带超时） public ushort[] ReadDRange(int startAddress, int wordCount) { var request = BuildDReadRequest(startAddress, wordCount); _socket.SendTimeout = 3000; _socket.ReceiveTimeout = 3000; try { _socket.Send(request); var response = new byte[1024]; int received = _socket.Receive(response); return ParseDReadResponse(response.Take(received).ToArray()); } catch (SocketException ex) when (ex.SocketErrorCode == SocketError.TimedOut) { throw new TimeoutException($"读取D{startAddress}超时，请检查PLC连接或地址是否正确"); } }

提示：_socket.ReceiveTimeout必须在每次Receive()前设置！.NET 的 Socket 对象会重用上次设置的超时值，但若上一次是 100ms（心跳），这次是 3000ms（读数据），不重设就会沿用 100ms，必然超时。这是血泪经验——某同学调试三天找不到原因，最后发现是忘了这行。

3.3 任务调度器：用状态机驱动立体仓库出入库流程

立体仓库的“自动”本质是状态流转。本方案不写死流程，而是定义一个TaskState枚举和TaskScheduler类，用查表法驱动。例如入库任务状态机：Idle → AssignLane → MoveToShelf → ExtendFork → ConfirmStorage → Done。每个状态对应一个 PLC 地址写入（如M2000=1触发巷道分配），并监听下一个状态位（如M2001==1表示分配完成）。调度器主循环每 200ms 扫描一次当前任务状态，匹配状态机表，执行对应动作。关键设计是“防抖”：状态位必须保持至少 2 个扫描周期（400ms）才认为有效，避免 PLC 瞬间脉冲导致误触发。

// 状态机表（简化版） private readonly Dictionary<TaskState, StateAction> _stateMachine = new() { [TaskState.AssignLane] = new StateAction { WriteAddress = "M2000", WriteValue = 1, NextCheckAddress = "M2001", HoldCycles = 2 } }; // 主调度循环（在 Timer 中执行） private void ExecuteTaskCycle() { var currentTask = GetCurrentTask(); if (currentTask == null) return; var currentState = currentTask.State; if (!_stateMachine.TryGetValue(currentState, out var action)) return; // 写入动作信号 WriteBit(action.WriteAddress, action.WriteValue); // 检查下一状态是否满足（需持续 holdCycles 个周期） bool nextReady = true; for (int i = 0; i < action.HoldCycles; i++) { if (!ReadBit(action.NextCheckAddress)) { nextReady = false; break; } Thread.Sleep(200); // 等待下一个扫描周期 } if (nextReady) currentTask.State = GetNextState(currentState); }

注意：Thread.Sleep(200)在 WinForm 中是允许的，因为调度器运行在独立后台线程（Task.Run启动），不会阻塞 UI。但绝不能在 UI 线程 Sleep！本方案在Form.Load事件中启动后台调度线程，并用CancellationTokenSource管理生命周期，关闭窗体时自动取消。

3.4 日志记录器：结构化文本日志，支持按任务ID过滤

调试立体仓库时，最怕日志像天书：“2023-10-05 14:22:33.123 INFO: Send OK”。本方案日志强制包含 5 个字段：时间戳 | 线程ID | 日志级别 | 任务ID | 操作描述。例如：2023-10-05 14:22:33.123 | T001 | DEBUG | TASK-007 | Write D1000=5 (InboundTask)。所有日志写入log/yyyy-MM-dd.log文件，且提供 WinForm 内置日志查看器，支持按TASK-xxx正则过滤。关键实现是LogEntry类封装所有字段，Logger类用StreamWriter追加写入（非File.AppendAllText，避免高并发锁竞争）。

public class LogEntry { public DateTime Timestamp { get; set; } = DateTime.Now; public string ThreadId { get; set; } = Thread.CurrentThread.ManagedThreadId.ToString("D3"); public LogLevel Level { get; set; } public string TaskId { get; set; } = "N/A"; public string Message { get; set; } } public void Log(LogEntry entry) { var line = $"{entry.Timestamp:yyyy-MM-dd HH:mm:ss.fff} | {entry.ThreadId} | {entry.Level} | {entry.TaskId} | {entry.Message}"; lock (_logLock) // 防止多线程写冲突 { _writer.WriteLine(line); _writer.Flush(); // 确保立即写入磁盘，不缓存 } }

提示：_writer.Flush()是救命稻草。某次现场测试，PLC 突然断电，日志文件最后一条是“TASK-007 开始执行”，但没记录“执行失败”，导致无法判断是卡在哪个环节。加上Flush()后，每次写入都落盘，断电也能看到最新状态。

4. 常见问题排查：立体仓库通信中最容易翻车的 5 个点

做自动化项目，80% 的时间花在排查问题上。本方案整理了从某高校毕设答辩到某公司现场调试中，出现频率最高的 5 个“一查就跪”问题。每个问题都按“现象 → 原因 → 解决”给出可立即执行的动作，不讲虚的。

4.1 现象：上位机显示“连接成功”，但读取 D0 始终返回 0，且 PLC 端无任何通信日志

原因：FX5U 的以太网模块未启用 MC 协议。FX5U 出厂默认使用“SLMP”协议（用于 GX Works2 在线监视），而 MC 协议需在 PLC 参数中手动开启。
解决：用 GX Works2 连接 PLC → 左侧导航栏“参数” → “以太网端口设置” → “通信协议” → 勾选“MELSEC Communication Protocol（MC）” → 下载参数到 PLC。注意：必须下载，仅设置不下载无效。

4.2 现象：读取 D1000 成功，但读取 D10000 报错“地址超出范围”，而 D10000 在 GX Works2 中可正常监视

原因：FX5U 的 D 区地址范围受“扩展寄存器”设置限制。默认 D0-D7999，若要访问 D10000，需在 PLC 参数中将“扩展寄存器容量”设为 16K 或更大。
解决：GX Works2 → “参数” → “PLC系统参数” → “存储器容量设置” → “扩展寄存器（D）” → 设为 16384（即 D0-D16383）→ 下载参数。

4.3 现象：WinForm 界面卡死几秒，然后弹出“超时异常”，但网络 PING PLC IP 正常

原因：Windows 防火墙阻止了出站连接。虽然 PING 通，但 MC 协议使用 TCP 6000 端口，该端口默认被防火墙拦截。
解决：控制面板 → Windows Defender 防火墙 → “高级设置” → “出站规则” → 新建规则 → 程序路径（选你的 .exe）→ 允许连接 → 完成。或临时关闭防火墙测试（仅调试用）。

4.4 现象：同一台电脑上，GX Works2 能连上 PLC，但你的 C# 程序连不上，报“连接被拒绝”

原因：FX5U 的以太网模块设置了“连接数限制”。GX Works2 占用了一个连接，而 PLC 默认只允许 1 个 MC 协议连接。
解决：GX Works2 → “在线” → “以太网设置” → “连接数设置” → 将“MC协议连接数”改为 2 或更高 → 下载参数。注意：总连接数（SLMP+MC）不能超过硬件上限（FX5U 最大 8 个）。

4.5 现象：程序运行一段时间后，读取数据开始错乱，如 D1000 的值突然变成 D1001 的值

原因：TCP 粘包。多个响应帧被操作系统合并成一个Socket.Receive()返回，而你的解析器没处理分帧逻辑，把两个帧当做一个解析。
解决：在ReceiveBytes()方法中加入分帧逻辑。MC 协议响应帧头 2 字节固定为0x50 0x00，每次接收后扫描缓冲区，找到所有0x50 0x00起始位置，按帧长（第 11-12 字节）切分。本方案在ConnectionManager类中已内置SplitFrames(byte[] raw)方法，直接调用即可。

5. 毕设/课设验收与答辩技巧：让导师一眼看懂你的工作量

验收不是看你能不能跑起来，而是看你的设计有没有“工程感”——能否应对真实场景的波动，能否被别人接手维护，能否解释清楚每一个决策背后的权衡。我带过 3 届自动化毕设，见过太多同学答辩时被问一句“为什么用 WinForm 不用 WPF？”就卡壳。下面这些技巧，是我从某高校答辩现场记录下来的高频问题及应答逻辑，不是背答案，而是建立你的技术叙事主线。

5.1 验收清单：5 个必演示、必截图、必写进报告的硬核点

导师验收时，往往只花 15 分钟看你的系统。这 5 个点必须提前准备好演示脚本和截图，缺一不可：

提示：别等答辩当天才做这些演示。我一般要求学生在第 3 周就完成这 5 个点的录制视频（每个 30 秒），存在 U 盘里，答辩时直接播放。导师没时间等你现场操作，视频最直观。

5.2 答辩话术：把“我做了什么”升级为“我解决了什么问题”

导师最讨厌听到“我用了 C#”“我写了 WinForm”“我连上了 PLC”。要切换成问题解决视角。例如：

• ❌ 错误说法：“我用 Socket 编程实现了通信。”

• ✅ 正确说法：“为解决立体仓库对通信实时性的严苛要求（<50ms 响应），我放弃 HTTP/WebSocket 等通用协议，采用原生 Socket + MC 二进制协议直连，实测端到端延迟稳定在 12ms。”

• ❌ 错误说法：“我做了个日志功能。”

• ✅ 正确说法：“为满足故障可追溯性要求，我设计结构化日志，强制包含任务 ID 和线程 ID，使导师或后续维护者能在 10 秒内定位任意一次任务失败的完整链路。”

记住：每个技术选型都要绑定一个具体问题。WinForm 不是因为“学过”，而是因为它“UI 线程隔离性好，避免多线程更新控件导致的崩溃”；JSON 配置不是因为“流行”，而是因为它“让非程序员（如现场调试工程师）也能修改地址映射，无需重新编译”。

5.3 答辩陷阱题预判：3 个必问、必须准备的答案

根据某高校近 3 年自动化毕设答辩记录，以下 3 个问题出现概率 100%，且答不好直接扣分：

Q1：如果 PLC 突然断电，你的上位机怎么保证任务不丢失？
→ 答：任务队列存储在 PLC 的 D 区（如 D1000-D1009），而 FX5U 的 D 区支持电池备份（需安装电池模块）。我的方案在任务写入 D 区前，先检查M100（电池电压正常标志），若为 OFF，则拒绝新任务并告警。同时，上位机内存中也缓存一份任务副本，断电恢复后比对 D 区与内存，自动补全未完成任务。

Q2：为什么不用 OPC UA？它不是更标准吗？
→ 答：OPC UA 确实标准，但它需要 PLC 额外安装 OPC UA Server（FX5U 需购买专用 license），且通信开销大（XML 封装），实测延迟达 80ms，不满足立体仓库高速节拍要求。而 MC 协议是三菱原生协议，零额外成本，延迟最低，是工业现场的务实选择。

Q3：你的方案能直接用在真实仓库吗？有什么风险？
→ 答：本方案已通过某实验室立体仓库模型验证（32 台堆垛机），但真实产线需增加两点：第一，增加硬件急停回路（本方案仅软件互锁）；第二，D 区任务队列需扩展为双缓冲（当前单缓冲），避免上位机写入时 PLC 正在读取导致数据错乱。这两点已在“后续优化”章节列出。

从那以后我每次带学生做自动化毕设，都强制他们在第 2 周提交一份《答辩问题预判表》，自己写出 5 个最可能被问的问题及答案，我们逐条打磨。不是为了背稿，而是逼他们真正想清楚：自己做的东西，到底解决了什么，又留下了什么。希望帮到你。

本文还有配套的精品资源，点击获取