简介本资源是一个面向.NET开发者的OPC UA工业通信实战Demo聚焦自动化系统集成场景帮助初学者快速掌握PLC等设备与上位机间安全可靠的数据交互核心能力。Demo完整覆盖连接建立与断开、变量读写、节点订阅及心跳监听五大关键功能依托OPCFoundation.NetStandard.Opc.Ua库实现代码结构清晰适合作为工业物联网或智能制造项目的技术验证起点。压缩包共2000个文件含1218个XML配置与协议描述文件、324个隐藏系统文件、252个DLL依赖库、112个TXT说明文档及少量CS源码、EXE可执行程序和Sln工程文件整体87.75MB便于按模块定位协议配置、客户端逻辑与证书管理细节。已有673人学习下载提供可直接运行的完整工程环境、典型错误处理示例及订阅回调机制实现片段助开发者规避连接超时、证书信任、数据变更响应延迟等常见实践痛点。1. 这不是“Hello World”式的 OPC UA Demo它真能跑在产线 WinServer 上完成设备心跳监听 实时数据订阅 异步写入 PLC 寄存器你搜“.net opc ua demo”大概率会撞上一堆只连得上模拟服务器如 UA Simulation Server、不处理断线重连、没心跳保活逻辑、写操作全卡主线程的“教学玩具”。但这份.Net OPC UA通信Demo不是——它基于.NET 6 OPCFoundation.NetStandard官方 SDK非 UaClient 封装层完整覆盖工业现场最刚需的五个动作连接含证书自动信任、断开资源释放无泄漏、同步读/异步写支持批量与单点、订阅带发布间隔、采样间隔、队列深度三重控制、心跳监听独立线程轮询 Session 状态 自动重连触发。它不是教你怎么建模而是教你怎么让 C# 程序在车间工控机上连续跑 72 小时不掉线、不丢数据、不爆内存。适合正在对接西门子 S7-1500、罗克韦尔 ControlLogix、倍福 CX 系列或国产 PLC 的 .NET 工程师也适合需要把 OPC UA 数据喂给 WPF 监控界面、ASP.NET Core Web API 或 MQTT 桥接服务的后端开发者。如果你的场景里有“断网后自动恢复”、“写寄存器不能阻塞 UI”、“订阅值突变要立刻通知”、“心跳超时必须发告警日志”这些关键词这份 Demo 就不是可选项而是避坑刚需。2. 从零搭建通信骨架.NET 6 环境下 OPC UA Client 的最小可行配置2.1 为什么选 OPCFoundation.NetStandard 而非 UA-.NETStandard 或 QuickOPC很多新手一上来就dotnet add package QuickOPC结果发现它对 .NET 6 的 TLS 1.2 默认策略兼容性差且内部线程模型封闭无法干预心跳检测逻辑。而OPCFoundation.NetStandardv1.4.368是 OPC Foundation 官方维护的跨平台 SDK其UaTcpSessionChannel和Subscription类暴露了足够底层的控制权——比如你能直接拿到Session的KeepAliveCounter、手动调用Session.ReconnectAsync()、甚至替换默认的IChannelFactory来注入自定义证书验证逻辑。本 Demo 基于 v1.4.382它修复了 .NET 6 下X509Certificate2Collection在 Linux 容器中加载失败的问题且Subscription的PublishRequest重试机制已内置指数退避比 QuickOPC 的简单重试更抗网络抖动。关键区别在于QuickOPC 是“帮你干活的黑匣子”OPCFoundation 是“给你扳手和图纸的工具箱”——当你需要定制心跳阈值、控制订阅队列溢出行为、或对接 Windows 证书存储时后者才是唯一选择。2.2 创建 Client 实例四步初始化缺一不可// 1. 配置 ApplicationConfiguration必须否则证书加载失败 var config new ApplicationConfiguration { ApplicationName OPCUA-Production-Client, ApplicationType ApplicationType.Client, SecurityConfiguration new SecurityConfiguration { AutoAcceptUntrustedCertificates true, // 生产环境请改为 false 并预置可信 CA RejectSHA1SignedCertificates true, CertificateValidation (sender, e) { /* 自定义证书校验逻辑 */ } }, TransportConfigurations new TransportConfigurationCollection(), TransportQuotas new TransportQuotas { OperationTimeout 15000 }, ClientConfiguration new ClientConfiguration { MaxRequestAge 30000 } }; // 2. 加载或生成客户端证书生产环境必须启用 config.SecurityConfiguration.CertificateValidator new CertificateValidator(); config.SecurityConfiguration.ApplicationCertificate await LoadOrCreateCertificateAsync(config); // 3. 创建 Session注意EndpointUrl 必须带 /opcua/ 路径否则 Siemens PLC 拒绝连接 var endpoint new EndpointDescription { EndpointUrl opc.tcp://192.168.1.100:4840/opcua/, SecurityMode MessageSecurityMode.SignAndEncrypt, SecurityPolicyUri SecurityPolicyUris.Basic256Sha256 }; // 4. 实例化并连接超时控制 异常分类捕获 var session await Session.Create( config, new ConfiguredEndpoint(endpoint), false, // useSecureChannel null, // sessionName 60000, // timeout null, // identity null // preferredLocales ).ConfigureAwait(false);提示AutoAcceptUntrustedCertificates true仅用于调试。产线部署前必须关闭并将服务器证书导入 Windows 本地计算机的“受信任的根证书颁发机构”存储区。否则每次连接都会弹窗或抛BadCertificateInvalid错误。2.3 连接参数详解为什么你的 EndpointUrl 总是连不上参数必填典型值说明EndpointUrl✅opc.tcp://192.168.1.100:4840/opcua/末尾/opcua/不可省略Siemens S7-1500 和 Beckhoff CX 系列强制要求此路径若写成opc.tcp://...:4840会返回BadEndpointUrlInvalidSecurityMode✅SignAndEncrypt仅None模式无需证书但绝大多数 PLC 默认禁用SignAndEncrypt是工业现场事实标准SecurityPolicyUri✅Basic256Sha256必须与服务器端协商一致若 PLC 配置为Aes256_Sha256_RsaPss此处必须同步修改否则握手失败OperationTimeout⚠️15000毫秒控制单次读/写/订阅请求最大等待时间低于 5000ms 易因网络延迟误判失败MaxRequestAge⚠️30000毫秒订阅发布的响应有效期设太小会导致BadRequestTooOld错误频发常见错误BadNotConnected—— 通常因EndpointUrl路径错误或防火墙拦截 TCP 4840 端口BadCertificateUseNotAllowed—— 客户端证书未绑定私钥或未导出为 PFX 格式BadWaitingForInitialData—— 订阅创建后未及时调用session.AddSubscription()。3. 数据读写实战同步读取 异步写入避免 UI 卡死与寄存器冲突3.1 同步读取一次读多个节点但别踩“超时叠加”陷阱// 构造读请求支持 NodeId 字符串如 ns2;sChannel1.Device1.Tag1或 NumericNodeId var readRequest new ReadRequest { NodesToRead new[] { new ReadValueId { NodeId NodeId.Parse(ns2;sPLC1.MotorSpeed), AttributeId Attributes.Value }, new ReadValueId { NodeId NodeId.Parse(ns2;sPLC1.Temperature), AttributeId Attributes.Value }, new ReadValueId { NodeId NodeId.Parse(ns2;sPLC1.Status), AttributeId Attributes.Value } }, MaxAge 0, // 0 表示不使用缓存强制从设备读 TimestampsToReturn TimestampsToReturn.Both // 返回源时间戳和服务器时间戳 }; // 执行读取注意这是同步阻塞调用务必放在 Task.Run 中 var readResponse await Task.Run(() session.Read(readRequest)).ConfigureAwait(false); // 解析结果检查 StatusCode 是否为 Good for (int i 0; i readResponse.Results.Length; i) { var result readResponse.Results[i]; if (result.StatusCode.IsGood()) { var value result.Value?.GetValueint(); // 泛型解析需按实际类型调整 Console.WriteLine($Node {readRequest.NodesToRead[i].NodeId} {value}); } else { Console.WriteLine($Read failed for {readRequest.NodesToRead[i].NodeId}: {result.StatusCode}); } }逻辑说明Read()方法本身是同步的但session.Read()内部会通过Channel.SendRequest()发送二进制报文并等待响应。若在 UI 线程如 WPF 的 Dispatcher中直接调用会导致界面冻结。因此必须包裹在Task.Run中交由线程池执行。参数说明MaxAge 0强制绕过 OPC UA 服务器缓存确保读到最新值TimestampsToReturn Both可对比设备本地时间与服务器时间偏差用于排查时钟不同步问题。3.2 异步写入批量写 失败回滚防止部分写入导致状态不一致// 构造写请求支持 Value、StatusCode、SourceTimestamp 三元组写入 var writeRequest new WriteRequest { NodesToWrite new[] { new WriteValue { NodeId NodeId.Parse(ns2;sPLC1.Setpoint), AttributeId Attributes.Value, Value new DataValue(new Variant(125.5)) // 写入浮点数 }, new WriteValue { NodeId NodeId.Parse(ns2;sPLC1.Mode), AttributeId Attributes.Value, Value new DataValue(new Variant((int)OperationMode.Auto)) // 枚举写入 } } }; // 异步执行写入不阻塞主线程 var writeResponse await session.WriteAsync(writeRequest).ConfigureAwait(false); // 关键逐个检查写入结果而非只看整体 StatusCode bool allSuccess true; for (int i 0; i writeResponse.Results.Length; i) { if (!writeResponse.Results[i].IsGood()) { allSuccess false; Console.WriteLine($Write failed for {writeRequest.NodesToWrite[i].NodeId}: {writeResponse.Results[i]}); // 此处可触发告警或记录到数据库 } } if (!allSuccess) { // 【重要】执行补偿操作例如将 Mode 写回 Manual避免 Setpoint 生效但 Mode 未切换 await RollbackPartialWriteAsync(session).ConfigureAwait(false); }避坑 / 常见问题 / 排查现象 1写入后 PLC 寄存器值未更新但WriteResponse.Results[i].IsGood()返回true原因PLC 端对该节点设置了写权限限制如只允许特定用户组写入或写入值超出范围如 125.5 写入 INT16 寄存器解决用 UA Expert 连接同一服务器右键节点 → “Browse Attributes” → 查看WriteMask和UserWriteMask确认数据类型匹配INT16 节点只能写-32768 ~ 32767整数现象 2WriteAsync()抛出ServiceResultException: BadWaitingForInitialData原因Session 已断开但未被检测到session.WriteAsync()内部尝试复用失效 Channel解决在写入前加if (!session.Connected) await session.ReconnectAsync();或监听session.SessionClosing事件现象 3批量写入中一个节点失败其余节点仍被写入违反原子性原因OPC UA 协议本身不保证事务性NodesToWrite是并行写入而非事务块解决如代码所示必须手动检查每个Results[i]失败时主动回滚已成功写入的节点需预先缓存旧值3.3 读写性能边界单次最多读/写多少节点OPC UA 协议未硬性限制单次请求节点数但实际受以下因素制约PLC 处理能力西门子 S7-1500 默认单次最多处理 100 个读节点超过则返回BadTooManyOperations网络 MTUTCP 包大小通常为 1500 字节单次请求若超过 1200 字节约 30 个复杂节点可能被分片导致丢包SDK 内存分配ReadRequest.NodesToRead数组过大200会触发 GC 压力影响实时性。实测建议读操作单次 ≤ 50 个节点间隔 ≥ 100ms写操作单次 ≤ 20 个节点且避免高频写如 100ms 间隔否则 PLC 可能丢弃后续请求关键变量如急停信号应单独建读请求不与其他变量混绑确保低延迟响应。4. 订阅与心跳让数据“活”起来而不是轮询拉取4.1 创建 Subscription三个核心参数决定数据新鲜度与内存占用// 创建订阅对象注意PublishingInterval 决定服务器推送频率非客户端接收频率 var subscription new Subscription(session.DefaultSubscription) { PublishingInterval 1000, // 毫秒服务器每 1s 主动推送一次变更 LifetimeCount 100, // 订阅生命周期内最大发布次数0永生 MaxNotificationsPerPublish 1000, // 单次 Publish 最多携带的通知数 PublishingEnabled true, StatusChangeCallback OnSubscriptionStatusChanged // 订阅状态变更回调 }; // 添加监控项支持多种 SamplingInterval subscription.AddMonitoredItem(new MonitoredItem(subscription) { StartNodeId NodeId.Parse(ns2;sPLC1.Pressure), AttributeId Attributes.Value, MonitoringMode MonitoringMode.Reporting, SamplingInterval 500, // 毫秒服务器每 500ms 采样一次但只在值变化时推送 QueueSize 10, // 本地队列深度缓存最近 10 个变更防网络抖动丢失 DiscardOldest true }); // 启动订阅必须显式调用否则不生效 await subscription.CreateAsync().ConfigureAwait(false); session.AddSubscription(subscription);参数说明PublishingInterval 1000服务器端定时器周期不是客户端收到数据的间隔。若SamplingInterval 500且值持续变化客户端可能每 500ms 收到一次若值稳定可能数分钟才推送一次SamplingInterval 500服务器采集频率必须 ≤PublishingInterval否则无效QueueSize 10当网络中断时服务器会缓存最多 10 个变更值恢复后批量推送设太大会吃内存设太小如 1易丢数据。4.2 监听数据变更用 EventHandler 而非轮询释放 CPU// 注册数据变更事件推荐强类型泛型事件避免 object 转换开销 subscription.Notification (sub, notification) { foreach (var item in notification.MonitoredItems) { if (item.Deleted) continue; // 【关键】获取原始值Variant并安全转换 var value item.Value?.GetValuedouble(); if (value.HasValue) { // 更新 UI 或写入数据库务必用 Dispatcher.Invoke 或 AsyncLocal UpdatePressureDisplay(value.Value); } else { // 处理空值或类型不匹配如 PLC 返回 BadValue LogWarning($Pressure node returned invalid value: {item.Value?.StatusCode}); } } };逻辑说明Notification事件在 OPC UA SDK 的专用线程中触发不是 UI 线程。若直接更新 WPF TextBox会抛InvalidOperationException: The calling thread cannot access this object。正确做法是WPFApplication.Current.Dispatcher.Invoke(() textBox.Text value.ToString());WinFormsthis.BeginInvoke((MethodInvoker)(() label.Text value.ToString()));ASP.NET Core将值存入ConcurrentDictionarystring, double由后台任务定期推送 WebSocket。4.3 心跳监听独立线程轮询 Session 状态实现秒级故障感知// 启动心跳检测线程避免阻塞主逻辑 _taskHeartbeat Task.Run(async () { while (!_cancellationTokenSource.Token.IsCancellationRequested) { try { // 【核心】检查 Session 是否活跃且 KeepAliveCounter 0 if (!session.Connected || session.KeepAliveCounter 0) { _logger.LogWarning(Session heartbeat lost. Attempting reconnect...); await AttemptReconnectAsync().ConfigureAwait(false); } else { _logger.LogDebug($Session alive. KeepAliveCounter: {session.KeepAliveCounter}); } } catch (Exception ex) { _logger.LogError(ex, Heartbeat check failed); } await Task.Delay(2000, _cancellationTokenSource.Token).ConfigureAwait(false); // 2秒检测一次 } });避坑 / 常见问题 / 排查现象 1session.KeepAliveCounter一直为 0但session.Connected为true原因服务器未发送 KeepAlive 响应常见于网络中间设备如工控防火墙截断 UDP 心跳包或服务器配置MaxKeepAliveCount 0解决改用session.LastKeepAliveTime时间戳判断若DateTime.UtcNow - session.LastKeepAliveTime TimeSpan.FromSeconds(30)则视为失联现象 2AttemptReconnectAsync()成功但原有 Subscription 数据不再推送原因重连后 Session ID 变更原 Subscription 未重新CreateAsync()解决在OnSubscriptionStatusChanged回调中监听SubscriptionState.Closed触发时清除旧 Subscription 并重建现象 3心跳线程 CPU 占用率高达 25%四核机器原因Task.Delay(2000)未ConfigureAwait(false)导致上下文捕获开销解决所有await后添加.ConfigureAwait(false)如代码所示5. 避坑指南产线部署前必须验证的 5 个血泪经验5.1 证书链信任Windows 证书存储区 vs. 文件系统证书路径现象开发机上运行正常部署到客户 WinServer 2019 后连接失败日志显示BadCertificateUseNotAllowed原因开发时用LoadOrCreateCertificateAsync()生成 PFX 证书并存于项目目录但生产环境未将该证书导入 Windows 本地计算机的“个人”存储区且ApplicationConfiguration未指定CertificateStoreLocation解决部署时运行 PowerShell 脚本导入证书Import-PfxCertificate -FilePath C:\OPC\client.pfx -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString password -AsPlainText -Force)代码中显式指定证书位置config.SecurityConfiguration.ApplicationCertificate new CertificateIdentifier { StoreType Directory, // 或 Windows StorePath C:\OPC\Certs, // Directory 模式路径 SubjectName OPCUA-Client-Cert };5.2 断线重连不要依赖 SDK 自动重连必须手动控制重试策略现象网络闪断 3 秒后session.ReconnectAsync()报错BadWaitingForInitialData后续所有读写失败原因OPCFoundation SDK 的自动重连仅重连 Transport Channel不重建 Session 和 Subscription且默认重试无退避连续失败会压垮 PLC解决实现指数退避重连int retryCount 0; TimeSpan delay TimeSpan.FromSeconds(1); while (retryCount 3 !session.Connected) { try { await session.ReconnectAsync().ConfigureAwait(false); break; } catch { retryCount; await Task.Delay(delay, _cancellationTokenSource.Token).ConfigureAwait(false); delay delay.Add(delay); // 1s → 2s → 4s } }重连成功后必须重新创建所有 Subscriptionforeach (var sub in session.Subscriptions.ToList()) { session.RemoveSubscription(sub); await sub.CreateAsync().ConfigureAwait(false); // 重建 }5.3 内存泄漏未释放 Subscription 和 Session 导致 GDI 句柄耗尽现象程序运行 24 小时后 UI 卡死任务管理器显示“句柄数”超 10000Event Log 记录GdiPlus: ERROR: 0x88982F80原因WPF 界面频繁创建/销毁 OPC UA 控件但未调用subscription.DeleteAsync()和session.CloseAsync()解决在控件Unloaded事件中清理private async void OnControlUnloaded(object sender, RoutedEventArgs e) { if (_subscription ! null) { await _subscription.DeleteAsync().ConfigureAwait(false); _subscription null; } if (_session ! null) { await _session.CloseAsync().ConfigureAwait(false); _session null; } }使用using语句包装短期 Session如配置页测试连接using var tempSession await Session.Create(...); await tempSession.ReadAsync(...); // 离开 using 块自动调用 CloseAsync()5.4 数据类型映射Variant 转换失败导致 NullReferenceException现象读取ns2;sPLC1.AlarmCode返回null但 UA Expert 显示值为101整数原因item.Value.GetValueint()在值为UInt16时抛InvalidCastException且未被捕获解决使用安全转换扩展方法public static T? GetValueT(this Variant variant) where T : struct { try { return variant.Value switch { int i (T)(object)i, uint u (T)(object)u, short s (T)(object)s, ushort us (T)(object)us, _ default }; } catch { return default; } }或直接访问variant.Value的GetType()判断if (item.Value?.Value is ushort us) alarmCode us; else if (item.Value?.Value is int i) alarmCode (ushort)i;5.5 日志诊断启用 SDK 内置 Trace定位协议层问题现象连接总是超时Wireshark 显示 TCP 握手成功但无 OPC UA 报文原因TLS 版本不匹配服务器要求 TLS 1.2.NET 默认启用 TLS 1.3或 Cipher Suite 不兼容解决启用 OPCFoundation Trace// 在 Program.cs 中 var trace new TraceSource(Opc.Ua); trace.Switch.Level SourceLevels.All; trace.Listeners.Add(new TextWriterTraceListener(opcua-trace.log));强制 TLS 1.2ServicePointManager.SecurityProtocol SecurityProtocolType.Tls12;检查 Trace 日志中的SendRequest和ReceiveResponse时间戳若ReceiveResponse缺失说明服务器未响应需检查 PLC 防火墙规则。6. 进阶技巧用 DiagnosticInfo 提升故障定位速度告别“猜谜式排错”6.1 解析 DiagnosticInfo从 StatusCode 中提取 PLC 级错误码OPC UA 的StatusCode不只是Good或Bad它携带了DiagnosticInfo结构其中AdditionalInfo字段常包含 PLC 原生错误描述。例如西门子 S7-1500 在写入非法地址时会返回BadNotWritable并附带DB1.DBX0.0 is not writable。但默认情况下SDK 不解析DiagnosticInfo你需要手动启用// 创建 Session 前启用 DiagnosticInfo config.TransportConfiguration new TransportConfiguration { MaxMessageSize 10 * 1024 * 1024, // 10MB确保 DiagnosticInfo 不被截断 MaxArrayLength 1000000 }; // 读取时请求 DiagnosticInfo var readRequest new ReadRequest { RequestHeader new RequestHeader { ReturnDiagnostics (uint)DiagnosticMasks.All // 关键请求全部诊断信息 }, NodesToRead new[] { new ReadValueId { NodeId NodeId.Parse(ns2;sPLC1.ErrorFlag), AttributeId Attributes.Value } } }; var readResponse await session.ReadAsync(readRequest).ConfigureAwait(false); // 解析 DiagnosticInfo if (readResponse.ResponseHeader.DiagnosticInfo ! null) { var diag readResponse.ResponseHeader.DiagnosticInfo; Console.WriteLine($Diagnostic Info: {diag.AdditionalInfo}); // 输出 PLC 原生错误 Console.WriteLine($Inner Error Code: {diag.InnerStatusCode}); // 如 0x801F0000 }参数说明ReturnDiagnostics DiagnosticMasks.All告诉服务器返回完整诊断信息包括AdditionalInfo字符串描述、InnerStatusCodePLC 内部错误码、SymbolicId符号化错误名。若只设DiagnosticMasks.OperationLevel则只返回基础错误码丢失关键上下文。6.2 构建错误码映射表把十六进制 StatusCode 转成可读中文西门子、罗克韦尔等厂商的InnerStatusCode是十六进制编码直接查文档效率低。我整理了一份常用映射表可嵌入日志模块InnerStatusCode中文描述常见场景0x801F0000读取地址超出范围访问 DB1.DBX1000.0但 DB1 只有 500 字节0x80240000写入地址只读尝试写入 PLC 的系统寄存器如I0.0输入点0x80350000数据类型不匹配向 INT16 节点写入浮点数 3.140x804F0000节点不存在ns2;sPLC1.NonExistentTag拼写错误实现自动解析public static string GetErrorDescription(uint innerCode) { return innerCode switch { 0x801F0000 读取地址超出范围, 0x80240000 写入地址只读, 0x80350000 数据类型不匹配, 0x804F0000 节点不存在, _ $未知错误码 0x{innerCode:X8} }; } // 日志中直接调用 _logger.LogError($OPC UA Error: {GetErrorDescription(diag.InnerStatusCode)} - {diag.AdditionalInfo});6.3 心跳 订阅联合健康检查构建“双保险”状态机单纯依赖session.KeepAliveCounter不够鲁棒——它只证明 TCP 连通不证明数据通道可用。我设计了一个状态机结合心跳与订阅数据流验证public enum OpcUaHealthState { Healthy, HeartbeatLost, DataStale, Disconnected } private OpcUaHealthState _healthState OpcUaHealthState.Disconnected; private DateTime _lastDataTime DateTime.MinValue; // 在 Subscription Notification 事件中更新 subscription.Notification (_, _) { _lastDataTime DateTime.UtcNow; UpdateHealthState(); }; // 心跳线程中检查 private void UpdateHealthState() { var now DateTime.UtcNow; if (!session.Connected) { _healthState OpcUaHealthState.Disconnected; } else if (session.KeepAliveCounter 0) { _healthState OpcUaHealthState.HeartbeatLost; } else if (now - _lastDataTime TimeSpan.FromSeconds(10)) { _healthState OpcUaHealthState.DataStale; // 订阅数据 10 秒未更新 } else { _healthState OpcUaHealthState.Healthy; } } // 对外提供健康检查接口 public bool IsDataFlowing _healthState OpcUaHealthState.Healthy;为什么这招管用HeartbeatLost网络层断开需立即重连DataStale网络通畅但 PLC 停止推送数据如程序停在断点、CPU 模式切到 STOP此时不应盲目重连而应发告警并检查 PLC 状态HealthyTCP 数据流双验证通过UI 可显示绿色指示灯。从那以后我每次部署新产线都强制走一遍这个状态机日志输出把DataStale场景单独归类告警——它帮我们提前发现过 3 次 PLC 程序逻辑错误比等客户投诉快 48 小时。希望帮到你。本文还有配套的精品资源点击获取