活字格12.1原生OPC UA客户端命令深度解析

1. 项目概述：为什么一个低代码平台要原生支持 OPC UA 客户端命令？

活字格 12.1 这个版本更新，我第一时间下载安装后没急着点开设计器，而是先翻了下 release notes 里关于“OPC UA”的那几行字——不是因为多爱看文档，而是过去三年里，我用活字格做过 7 个工业现场的数据集成项目，其中 5 个卡在 OPC UA 接入环节，要么靠写 C# 插件硬扛，要么拖 Node-RED 做中间桥接，再把结果塞进活字格的 Web API。每次交付前都要给客户额外解释“为什么我们的低代码平台不能直接连 PLC”，那种心虚感，干过工业集成的都懂。

这次标题里写的“原生 OPC UA 客户端命令”，不是加个按钮、配个地址就叫原生。它意味着活字格运行时（也就是你发布的 Web 应用背后那个 .NET Core 服务）内置了符合 OPC Foundation 认证的 UA TCP 栈，能直接发起 Session、建立 SecureChannel、执行 Read/Write/Call 等标准服务调用，全程不依赖外部进程、不走 HTTP 中转、不强制要求 Windows 系统——这点特别关键。很多同行还在用“活字格调用 Python 脚本去连 KEPServerEX”，本质上还是两层架构，出问题要查三处日志；而 12.1 的命令是直接跑在活字格服务进程里的，错误堆栈能精准定位到哪一行表达式、哪个节点 ID、哪次超时。

我拿手头一个真实产线做测试：西门子 S7-1500 + TIA Portal V18 配置的 OPC UA 服务器，启用匿名访问和 Basic256Sha256 加密。过去用旧版活字格，必须在服务器上装 KEPServerEX，再配置一个 OPC UA to REST 的通道，活字格前端通过 Ajax 轮询那个 REST 接口；现在，我在活字格设计器里拖一个“OPC UA 读取”命令，填入opc.tcp://192.168.1.100:4840，点开节点浏览器，直接看到Objects > Station > PLC > GlobalDB > DB1 > Value1这个路径，选中后生成绑定表达式{OPCRead("Objects.Station.PLC.GlobalDB.DB1.Value1")}，发布后刷新页面，数值实时跳动——整个过程从原来平均 3 小时配置+调试，压缩到 8 分钟内完成。这不是功能“有无”的问题，而是架构层级的跃迁：低代码平台第一次真正站在了工业通信协议的语义层上，而不是在应用层打补丁。

所以如果你正面临这些场景，这个更新对你价值极大：

• 产线 MES 系统需要直连多品牌 PLC（西门子、罗克韦尔、倍福），但团队里没有专职的 OPC 开发工程师；
• 客户明确要求“所有数据链路必须可控、可审计、不引入第三方中间件”，你不能再偷偷装 Node-RED；
• 项目预算紧张，没法为每个接入点单独采购 KEPServerEX 许可证（单点授权动辄上万）；
• 你需要在移动端（uniapp 打包的 App）里展示实时设备状态，但传统方案因跨域或证书问题无法在 iOS 上稳定运行。

这 9 个命令不是孤立的功能点，它们共同构成了一个完整的 OPC UA 会话生命周期管理能力：从连接、发现、读写、方法调用，到异常重连、会话保持、批量操作。接下来我会带你逐个拆解，不讲抽象概念，只说你在设计器里点哪里、输什么、为什么这么输、输错会报什么错——就像我当年带新人时，在工控柜旁一边接线一边教的那样。

2. 核心设计逻辑与技术选型深挖：为什么是这 9 个命令？为什么不是 SDK 封装？

2.1 这 9 个命令的完整清单与设计意图

活字格 12.1 并没有把 OPC UA 协议栈全量暴露给用户，而是做了非常务实的裁剪。我对照 OPC UA Part 4（Services）规范和实际工业现场高频需求，梳理出这 9 个命令的底层映射关系：

注意两个关键设计点：
第一，“OPCConnect”和“OPCDisconnect”是唯一两个同步阻塞型命令。这是刻意为之——连接建立失败必须立刻反馈（比如证书不信任、端口不通、用户名密码错），不能让用户以为“正在连”，结果后台静默重试 30 秒才报错。我实测过，当输入一个不存在的 IP 地址时，OPCConnect在 2.8 秒后抛出System.Net.Sockets.SocketException，错误信息里直接包含“No such host is known”，比某些国产 OPC 调试软件的“连接超时”提示清晰十倍。

第二，所有读写类命令（Read/Write/Subscribe）都强制要求先执行 OPCConnect。这不是为了增加步骤，而是 OPC UA 协议本身的强会话约束：你不能跳过 Session 创建就直接发 Read 请求。活字格用这种“硬性依赖”倒逼开发者理解协议本质——很多现场问题（比如读数始终为 Bad）根源就是会话未激活或已过期，而不是节点路径写错。

2.2 为什么不用封装好的 OPC UA .NET SDK？——性能与安全的双重权衡

有朋友问：“既然 .NET 生态有成熟的Opc.UaFx.Client库，活字格为什么不直接封装它？” 我专门约了活字格架构师喝了顿茶，得到的答案很实在：不是不能，而是不敢。

Opc.UaFx.Client是个优秀的开源库，但它默认启用了“自动重连”和“会话保持”机制。在工业现场，PLC 重启、网络抖动、防火墙策略变更太常见了。如果活字格底层无脑套用它的自动重连，就会出现两种灾难性情况：

• 资源泄漏：每次重连都新建一个UaTcpSessionChannel，而旧 Channel 因未显式关闭，TCP 连接处于TIME_WAIT状态。我们一个客户现场曾因此在 72 小时内耗尽了 Windows 服务器的 65535 个端口，导致所有新连接失败；
• 状态错乱：自动重连后，旧的 MonitoredItem 订阅关系可能失效，但客户端仍按老规则推送数据，导致前端显示“设备运行中”而实际 PLC 已停机。

活字格的选择是：自己实现精简版 UA TCP 栈，只保留最核心的 Session/SecureChannel 管理，把重连逻辑完全交给开发者控制。比如OPCConnect命令有个关键参数RetryCount（默认 0），你设成 3，它就会在首次失败后，间隔 1 秒、2 秒、4 秒各重试一次，每次失败都触发OnError事件，你可以在此写日志、发告警、切备用服务器地址。这种“可控的脆弱性”，远比“不可控的健壮性”更适合工业系统。

另一个常被忽略的点是证书信任链处理。Opc.UaFx.Client默认信任所有证书（开发方便，生产危险），而活字格 12.1 强制要求：若服务器使用自签名证书，必须提前将证书导入活字格服务所在机器的“受信任的根证书颁发机构”存储区。我在测试时故意没导入，OPCConnect直接返回BadCertificateInvalid错误，并附带证书指纹供你核对——这看似增加了部署步骤，实则堵死了生产环境最常被忽视的安全缺口。

2.3 与 Node-RED / KEPServerEX 的本质区别：谁在承担协议解析工作？

网上搜“opc ua node-red 实现 opc ua 转 mqtt”，结果铺天盖地。但很少有人说清一个事实：Node-RED 本身不解析 OPC UA 二进制协议，它依赖node-opcua这个 JavaScript 库。而 JS 解析二进制流的性能，天然弱于 .NET 原生实现。我做过对比测试：同一台 i5-8250U 的工控机，用 Node-RED 每秒最多处理 120 个 OPC UA Read 请求；换成活字格 12.1 的原生命令，轻松跑到 850+ QPS（测试条件：读取 10 个 Int32 节点，超时 100ms）。

更关键的是数据语义保真度。Node-RED 的 OPC UA 节点输出的是 JSON，比如一个DateTime类型节点，它会转成"2024-05-20T08:30:45.123Z"字符串；而活字格的OPCRead返回的是 .NET 的DateTime对象，前端绑定时可直接用{value:yyyy-MM-dd HH:mm:ss}格式化，毫秒级精度不丢失。这对需要做时间序列分析的场景（比如计算设备单次运行时长）至关重要。

至于 KEPServerEX，它本质是个 OPC UA 服务器代理——你让活字格连 KEPServerEX，KEPServerEX 再去连真正的 PLC。多一层转发，就多一重故障点：KEPServerEX 的许可证到期、License Server 不可达、内部队列积压……而活字格 12.1 是直连，只要 PLC 的 OPC UA 服务开着，就能通。当然，KEPServerEX 的优势在于协议转换（比如把 Modbus RTU 设备转成 OPC UA），这不属于活字格的职责范围，二者是互补而非替代关系。

3. 9 个命令全流程实操：从零开始搭建一个设备监控页面

3.1 环境准备与前置验证：别跳过这 3 分钟，否则后面全是坑

在活字格设计器里新建一个空白页面前，请务必完成以下验证。我见过太多人卡在这一步，最后发现是基础环境问题：

第一步：确认 OPC UA 服务器已就绪
不要依赖“PLC 程序已下载”这个说法。打开任意 OPC UA 调试软件（推荐免费的 UaExpert），输入服务器地址opc.tcp://192.168.1.100:4840，点击连接。成功后，在地址空间树里展开Objects→Station，你应该能看到类似PLC_1或Controller的子节点。如果连不上，优先检查：

• PLC 防火墙是否放行 4840 端口（西门子默认是 4840，罗克韦尔可能是 49320）；
• TIA Portal 中 OPC UA 服务器是否启用（Options > Settings > OPC UA Server > Enable）；
• 用户权限是否正确（匿名访问需勾选Allow Anonymous Login，否则OPCConnect会报BadUserAccessDenied）。

第二步：验证活字格服务账户权限
活字格 Web 应用默认以IIS APPPOOL\GrapeCity身份运行。这个账户必须有权限读取本地证书存储区。打开服务器上的certlm.msc（本地计算机证书管理器），展开受信任的根证书颁发机构 > 证书，确认你的 OPC UA 服务器证书（或其 CA 证书）已在此处。如果没有，右键证书 →所有任务 > 导入，选择“本地计算机”，并勾选“将此证书放入下列存储区” →受信任的根证书颁发机构。

提示：如果服务器用的是公共 CA 签发的证书（如 Let's Encrypt），这步可跳过。但工业现场 95% 以上都是自签名证书，务必手动导入。

第三步：设计器插件检查
打开活字格设计器 →帮助 > 关于，确认版本号是12.1.xxx。然后进入工具 > 选项 > 扩展，查看OPC UA Client Commands是否已启用。如果灰色不可选，说明安装包未包含该模块——请重新下载完整版安装包（官网下载页明确标注“含工业协议扩展”）。

完成这三步后，你才算真正站在了起跑线上。接下来的所有操作，我都基于一个真实案例：监控一条包装线的 3 台变频器（VFD1/VFD2/VFD3），实时显示运行状态、频率设定值、当前输出频率，并提供“启动/停止”按钮。

3.2 第一个命令：OPCConnect —— 建立会话的 5 个必填参数详解

在页面设计器中，点击左侧工具箱的命令分类，找到OPCConnect命令，拖到画布上。双击打开属性面板，你会看到 7 个参数，但真正必须填的只有 5 个：

1. EndpointUrl（必填）：格式必须是opc.tcp://IP:Port，不能带路径、不能加/、不能用主机名（除非 DNS 解析已配置）。例如opc.tcp://192.168.1.100:4840。我曾因填了opc.tcp://vfd-server.local:4840导致连接失败，查日志才发现 DNS 解析超时——工业现场请一律用 IP。

2. SecurityPolicy（必填）：下拉菜单有None、Basic128Rsa15、Basic256、Basic256Sha256。这必须和 PLC 服务器配置严格一致。西门子 TIA Portal V18 默认是Basic256Sha256，罗克韦尔 Studio 5000 默认是Basic256。填错会直接报BadSecurityPolicyRejected。不确定时，先用 UaExpert 连一次，看连接详情里的 Security Policy 字段。

3. UserIdentity（可选但强烈建议填）：类型是OPCUserIdentity对象。即使服务器允许匿名，也建议填一个空对象{}，避免某些固件版本的兼容性问题。如果需要认证，填：

   { "Type": "UserName", "UserName": "admin", "Password": "123456" }

   注意：密码明文存储有风险，生产环境应结合活字格的“加密参数”功能，将密码存在配置文件中。

4. SessionName（必填）：这是你在活字格里给这个会话起的名字，用于后续所有命令引用。必须全局唯一，建议用业务含义命名，如PackLine_VFD_Session。别用Session1这种，后期维护会疯。

5. Timeout（必填）：单位毫秒，默认 10000（10 秒）。别贪大！工业现场网络延迟波动大，设成 30000 反而会让前端卡住。我的经验是：局域网设 3000，跨 VLAN 设 5000，有防火墙策略的设 8000。

其他两个参数：

• RetryCount：设 2 即可，配合RetryDelay（默认 1000ms）形成指数退避；
• KeepAliveInterval：默认 10000ms，即每 10 秒发一次心跳包维持会话。PLC 侧通常要求 30 秒内有心跳，这个值足够安全。

配置完，点击测试命令。如果返回Success: Connected to opc.tcp://192.168.1.100:4840，说明会话建立成功。此时，你可以在设计器的变量面板里看到一个名为PackLine_VFD_Session的会话变量，类型是OPCSession——这就是后续所有命令的操作手柄。

3.3 发现节点：OPCBrowse 命令的三层递进式探索法

会话建好了，但你还不知道要读哪个节点。OPCBrowse就是你的“探照灯”。拖一个OPCBrowse命令到画布，设置SessionName为PackLine_VFD_Session，其他参数留空，点击测试。返回结果是一个 JSON 数组，类似：

[ {"NodeId":"ns=2;i=5","DisplayName":"VFD1","NodeClass":"Object"}, {"NodeId":"ns=2;i=6","DisplayName":"VFD2","NodeClass":"Object"}, {"NodeId":"ns=2;i=7","DisplayName":"VFD3","NodeClass":"Object"} ]

这里的关键是理解NodeId的语法：ns=2;i=5表示命名空间索引 2，整数节点 ID 5。不同 PLC 命名空间不同，西门子通常是ns=2，罗克韦尔是ns=3。DisplayName是你在 TIA Portal 里给对象起的名字，这才是你该记住的。

但光有顶层对象不够，得往下钻。OPCBrowse支持BrowseDirection参数，设为Forward（默认），ReferenceTypeId设为Organizes（固定值i=35），NodeId填ns=2;i=5（即 VFD1 的 ID），再测试。这次返回：

[ {"NodeId":"ns=2;i=101","DisplayName":"Status","NodeClass":"Variable"}, {"NodeId":"ns=2;i=102","DisplayName":"FreqSetpoint","NodeClass":"Variable"}, {"NodeId":"ns=2;i=103","DisplayName":"FreqOutput","NodeClass":"Variable"}, {"NodeId":"ns=2;i=104","DisplayName":"ControlMethods","NodeClass":"Object"} ]

看到ControlMethods是个 Object，说明里面有可调用的方法。再对它Browse一次，NodeId填ns=2;i=104，ReferenceTypeId仍为i=35，返回：

[ {"NodeId":"ns=2;i=201","DisplayName":"Start","NodeClass":"Method"}, {"NodeId":"ns=2;i=202","DisplayName":"Stop","NodeClass":"Method"} ]

至此，你拿到了完整路径：

• 状态变量：VFD1.Status→ns=2;i=101
• 启动方法：VFD1.ControlMethods.Start→ns=2;i=201

注意：OPCBrowse返回的NodeId是二进制协议里的原始 ID，而活字格命令支持更友好的“路径式”写法。你完全可以不用记ns=2;i=101，直接在OPCRead命令里写VFD1.Status，活字格会在运行时自动解析。但建议你第一次用OPCBrowse把路径摸清楚，避免拼写错误。

3.4 实时读取：OPCRead 命令的 3 种用法与性能陷阱

现在可以读数据了。拖一个OPCRead命令，SessionName填PackLine_VFD_Session，NodeIds参数填一个数组：

["VFD1.Status", "VFD1.FreqSetpoint", "VFD1.FreqOutput"]

点击测试，返回：

[ {"NodeId":"VFD1.Status","Value":1,"StatusCode":"Good","SourceTimestamp":"2024-05-20T08:30:45.123Z"}, {"NodeId":"VFD1.FreqSetpoint","Value":50.0,"StatusCode":"Good","SourceTimestamp":"2024-05-20T08:30:45.124Z"}, {"NodeId":"VFD1.FreqOutput","Value":49.8,"StatusCode":"Good","SourceTimestamp":"2024-05-20T08:30:45.125Z"} ]

Value字段就是你要的值，StatusCode是 OPC UA 的状态码（Good表示正常），SourceTimestamp是 PLC 侧的时间戳，比活字格服务器时间更可信。

但这里有个巨大陷阱：别在页面加载时一次性读 100 个节点！
OPC UA 协议规定，单次 Read 请求最多携带 100 个节点，但实际性能取决于 PLC 处理能力。我测试过一台 S7-1200，当NodeIds数组超过 15 个时，响应时间从 15ms 暴涨到 220ms。解决方案是分组：

• 组 1（高频监控）：Status,FreqOutput,AlarmCode（每 1 秒读一次）
• 组 2（低频配置）：MaxFreq,AccelTime,DecelTime（每 30 秒读一次）
• 组 3（事件驱动）：只在用户点击“刷新参数”按钮时读

在活字格里，这通过定时器命令 + 不同的OPCRead实例实现。每个OPCRead命令独立配置NodeIds和Timeout，互不影响。

另外，OPCRead支持AttributeId参数，默认是Value（读值），也可设为DataType（读数据类型）、Description（读描述）。比如你想确认VFD1.Status确实是Int32类型，可以单独发一个AttributeId: DataType的请求，返回i=6（对应 Int32），避免前端类型转换出错。

3.5 实时推送：OPCSubscribe 命令的订阅-取消订阅闭环

轮询（Polling）适合低频数据，但对状态变化（如设备启停）必须用订阅（Subscription）。OPCSubscribe是活字格 12.1 最惊艳的设计——它让低代码平台第一次拥有了真正的“推”能力。

拖一个OPCSubscribe命令，SessionName填PackLine_VFD_Session，NodeIds填["VFD1.Status"]，PublishingInterval设为1000（毫秒），SamplingInterval设为100（毫秒）。这意味着：服务器每 100ms 检查一次VFD1.Status值，只要变化就立即上报；活字格客户端每 1000ms 向服务器发一次 Publish 请求，收取所有待推送的数据。

关键点来了：OPCSubscribe返回的不是数据，而是一个SubscriptionId（如12345）。这个 ID 必须保存下来，用于后续取消订阅。所以你要做三件事：

1. 在页面变量里创建一个VFD1_SubscriptionId，类型Number；
2. OPCSubscribe的OnSuccess事件里，写表达式：SetVariable("VFD1_SubscriptionId", result.SubscriptionId)；
3. 在页面OnUnload事件（用户离开页面时）里，拖一个OPCUnsubscribe命令，SessionName填PackLine_VFD_Session，SubscriptionId填VFD1_SubscriptionId。

提示：如果不取消订阅，PLC 侧的 MonitoredItem 会一直占用资源，长时间运行后可能导致服务器内存溢出。活字格没有自动清理机制，必须由你显式管理。

订阅成功后，数据会通过OnDataChange事件推送。在OPCSubscribe的OnDataChange里写：

SetVariable("VFD1_Status", result[0].Value); SetVariable("VFD1_LastUpdate", result[0].SourceTimestamp);

这样，只要VFD1.Status值一变，前端变量就实时更新，无需任何轮询。

3.6 远程控制：OPCCall 命令调用 PLC 方法的完整流程

最后是“启动/停止”按钮。拖一个按钮控件，点击事件里放OPCCall命令。SessionName填PackLine_VFD_Session，ObjectId填VFD1.ControlMethods（注意不是VFD1.ControlMethods.Start），MethodId填VFD1.ControlMethods.Start，Arguments留空（启动方法通常无参数）。

为什么ObjectId和MethodId要分开？因为 OPC UA 协议要求：Call 服务必须指定“对象节点 ID”和“方法节点 ID”，二者是父子关系。VFD1.ControlMethods是对象，VFD1.ControlMethods.Start是它下面的方法。

调用成功后，OPCCall返回result.StatusCode: Good。但要注意：方法调用成功 ≠ 设备真的启动了。PLC 程序里可能有互锁逻辑（比如“只有温度<80℃才能启动”），此时StatusCode仍是Good，但result.OutputArguments[0]可能返回false。所以严谨的做法是：

• 在OPCCall的OnSuccess里，检查result.OutputArguments[0]；
• 如果为false，弹窗提示“启动失败：温度过高，请检查冷却系统”。

停止按钮同理，只是MethodId换成VFD1.ControlMethods.Stop。

3.7 全流程收尾：OPCDisconnect 与错误处理的黄金组合

页面关闭前，必须执行OPCDisconnect。但别简单拖个命令就完事。工业现场最怕“假断开”——命令执行了，但 TCP 连接没真正关闭。活字格的OPCDisconnect会主动发送CloseSession请求，并等待服务器返回ResponseHeader.ServiceResult == Good。

更关键的是错误处理。在OPCConnect的OnError事件里，我写了这样的逻辑：

1. 记录详细错误日志（含EndpointUrl、SecurityPolicy、ErrorMessage）；
2. 弹窗提示用户：“OPC 连接失败，请检查网络或联系管理员”；
3. 启动一个定时器，30 秒后自动重试OPCConnect（避免用户反复点击）；
4. 若连续 3 次失败，切换到备用服务器地址（如opc.tcp://192.168.1.101:4840）。

这套机制让系统具备了基本的容错能力。而OPCDisconnect的OnError事件，我只做一件事：记录日志。因为断开失败通常不影响业务，下次连接时自然会重建。

4. 常见问题排查与独家避坑指南：那些文档里不会写的细节

4.1 连接失败的 5 种典型错误及秒级定位法

我把过去三个月客户现场遇到的连接问题，按发生频率排序，给出精准定位步骤：

实操心得：遇到连接问题，永远先用 UaExpert 复现。如果 UaExpert 也连不上，问题一定在 PLC 或网络层，跟活字格无关。这是节省时间的铁律。

4.2 数据读取不准的 3 个隐蔽原因

读到的值和 PLC HMI 显示不一致？别急着怀疑活字格，先查这三项：

原因 1：数据类型自动转换陷阱
PLC 里FreqSetpoint是REAL类型（32 位浮点），但活字格OPCRead默认按Double解析，可能产生微小误差（如50.0读成49.99999999999999）。解决方案：在OPCRead命令的DataType参数里，显式指定"Float"，强制按 32 位解析。

原因 2：时间戳来源混淆
OPCRead返回的SourceTimestamp是 PLC 时间，ServerTimestamp是 OPC 服务器时间。如果你用ServerTimestamp做数据对齐，会发现和 PLC 日志对不上。务必统一用SourceTimestamp。

原因 3：采样周期与 PLC 扫描周期冲突
S7-1500 的默认扫描周期是 10ms，但OPCRead每秒发 10 次请求（100ms 间隔），可能刚好错过 PLC 更新瞬间。解决方案：将OPCRead的Timeout设为500，SamplingInterval在OPCSubscribe中设为10，让数据推送更贴近 PLC 实时性。

4.3 性能优化的 4 个硬核技巧

活字格 12.1 的 OPC UA 命令性能很强，但用不好会拖垮整个系统：

技巧 1：合并读取，减少请求次数
别为每个变量单独建OPCRead。把同一批次更新的变量（如 VFD1 的 5 个状态）放在同一个OPCRead的NodeIds数组里。一次请求 5 个节点，比 5 次请求各 1 个节点，快 3 倍以上。

技巧 2：善用缓存，避免重复解析
OPCBrowse结果可以缓存。在页面OnLoad时执行一次OPCBrowse，把结果存入页面变量NodeMap，后续所有OPCRead都从NodeMap里取NodeId，避免每次都要遍历地址空间。

技巧 3：动态订阅，按需开启
不要一进页面就订阅所有节点。用“懒加载”：当用户点击某个 VFD 的卡片时，再执行OPCSubscribe；离开卡片区域时，执行OPCUnsubscribe。这样 10 台设备同时在线，实际只订阅当前聚焦的 1-2 台。

技巧 4：错误隔离，防止单点崩溃
一个OPCRead失败，不该导致整个页面卡死。在每个 OPC 命令的OnError里，只处理本命令的错误，用SetVariable设置一个LastError变量，前端用Visible: !IsEmpty(LastError)控制错误提示框显示。这样，VFD1 读取失败，VFD2 依然正常工作。

4.4 安全加固的 2 个必须动作

工业系统安全无小事，这两个配置必须做：

动作 1：禁用匿名访问（生产环境）
在 TIA Portal 中，取消勾选Allow Anonymous Login，创建专用 OPC UA 用户（如grapecity_ro只读，grapecity_rw读写）。活字格OPCConnect的UserIdentity填对应凭据。这样即使网络被嗅探，攻击者也无法获取数据。

动作 2：限制会话数量
在活字格服务配置文件web.config中，找到<add key="OPCUA.MaxSessions" value="10" />，根据服务器性能调整。默认 100 个会话，对一台 4 核 CPU 的服务器压力过大。我们客户现场设为 20，稳定运行半年无异常。

5. 场景延伸与能力边界：它能做什么，不能做什么？

5.1 能