从零手写C# OPC UA服务器：无依赖纯代码实现全解析

去年接一个设备联网项目时，甲方提了个挺折磨人的约束：现场内网完全隔离，不装 NuGet 包，不上第三方运行时，连部署目录都不能额外放 DLL。偏偏设备侧要对接 OPC UA 客户端，服务器端还得我们自己出。跑完一圈调研发现，市面上成熟库基本都有堆依赖的问题，尤其在纯内网环境下，认证、版本、离线部署全是麻烦。最后我咬咬牙，把 C# OPC UA 服务器端源码从零手写了一遍，全程纯代码实现，没有任何第三方库依赖。今天这篇就把整个过程完整拆开，从协议帧到地址空间，从会话管理到互操作性测试，聊清楚这条路到底怎么走通。

先说清楚受众：如果你只是要在项目里快速实现 OPC UA 通讯，正常选官方 SDK 或成熟开源协议栈就好。但如果你遇到的是离线环境、精简运行时、或者单纯想彻底搞懂 OPC UA 内部机制，那这篇手写服务端的过程应该能帮你省不少弯路。

1. 动手前先想清楚：无依赖方案到底图什么

1.1 没有第三方库的真实原因

很多人一听“纯代码实现”会下意识觉得是炫技。其实不是，我这次是被现实逼的。现场环境有三道坎：

第一，离线隔离。车间内网和互联网物理断开，NuGet 还原跑不通，手动拷贝依赖包又容易出现版本不一致的问题。而 OPC UA 相关的官方实现推了很久，像 Core 版本的协议栈通常依赖也不少，审计起来麻烦。

第二，运行时限制。部署机上安装的是精简版系统镜像，跑的还是 .NET Framework 老运行时。有些协议栈用到了较新的语言特性或系统 API，退回旧环境就要改一堆兼容代码。

第三，可维护性。甲方要求源码可控，第三方 npm/DLL 一多，安全问题、合规问题的排查成本就直线上升。而 OPC UA 本身是公开协议，只要按规范实现，代码里每一行都是可控的。

1.2 整体架构：把服务端拆成四层

OPC UA 服务端听起来很唬人，但底层要干的事无非四件：监听 TCP 连接、处理后端协议消息、维护节点数据、响应客户端读写请求。

所以我从第一版就开始把代码拆成四层，后面调试时非常省心。

• 传输层：负责 TCP 监听、连接维护、半包粘包处理。
• 通道层：负责 OPC UA 二进制协议的编解码，把字节流转成操作对象。
• 服务层：实现具体服务如 GetEndpoints、CreateSession、Read、Write、Browse。
• 信息模型层：维护节点、变量、方法、引用关系，相当于服务端的“内存数据库”。

分层的好处是什么？协议处理和服务逻辑分离以后，哪天想换成 UDP 传输或者共享内存传输，只需重写传输层。真实干活时我先实现通道层和服务层的核心流程，再回头补信息模型层，因为后面响应客户端读写的关键是数据怎么组织，而不是消息怎么解码。

2. 核心细节解析：OPC UA 二进制协议到底聊点什么

2.1 先认识 OPC UA TCP 帧

只有真正开始读协议规范时，你才会发现 OPC UA 的二进制协议没有想象中那么玄。它本质上就是一条 TCP 长连接上反复传递的“信封结构”。每个完整消息分三大部分：消息头、安全头、消息体（body）。

• 消息头：固定 8 字节，包含 3 字节消息类型（HEL、ACK、OPN、MSG、CLO 等）、1 字节 Chunk 类型（C 表示中间片，F 表示最终片）、4 字节消息长、4 字节通道 ID。
• 安全头：在安全策略为 None 的情况下，OpenSecureChannel 请求里是 4 字节序列号 + 4 字节请求 ID；建通道后变成通道 ID、Token ID、Sequence Number、Request ID。
• 消息体：编入具体的服务请求/响应内容。

卡住大多数人的地方在于数据编码。OPC UA 二进制协议里面，Int32、UInt32、字符串都有各自的规则，而且不同字段的字节序还不一定一致。网上很多半桶水的文章会把“整个协议都是小端序”挂在嘴边，实际踩坑时你会发现头部字段和服务体字段要分开处理。我实现时统一写了一个 BinaryDecoder 和 BinaryEncoder，把每条规则都收敛到这两个类里，单个字段的字节序错了也只需要改一处。

这里放一个最核心的解码器片段，后面所有服务实现都建立在它上面：

csharp复制public class BinaryDecoder
{
    private readonly byte[] _buffer;
    private int _position;

    public BinaryDecoder(byte[] buffer)
    {
        _buffer = buffer;
        _position = 0;
    }

    public bool ReadBoolean()
    {
        return _buffer[_position++] != 0;
    }

    public int ReadInt32()
    {
        int value = BitConverter.ToInt32(_buffer, _position);
        _position += 4;
        return value;
    }

    public uint ReadUInt32()
    {
        uint value = BitConverter.ToUInt32(_buffer, _position);
        _position += 4;
        return value;
    }

    public byte[] ReadBytes(int length)
    {
        if (length <= 0) return Array.Empty<byte>();
        var data = new byte[length];
        Array.Copy(_buffer, _position, data, 0, length);
        _position += length;
        return data;
    }

    public string ReadString()
    {
        int length = ReadInt32();
        if (length == -1) return null;
        if (length == 0) return string.Empty;
        var bytes = ReadBytes(length);
        return Encoding.UTF8.GetString(bytes);
    }

    public byte[] ReadByteString()
    {
        int length = ReadInt32();
        if (length == -1) return null;
        return ReadBytes(length);
    }
}

这个解码器就是整个服务端的口子，所有从 TCP 收到的字节都会先走一遍它。

2.2 SecureChannel、Session、Subscription 三条命脉

很多初学者搞不清 OPC UA 里“通道”和“会话”是什么关系，这里用一个生活化类比：通道是电话线路，会话是通话双方约定好的通话身份，订阅是电话里实时播报的频道。 线路负责传输，身份决定权限，频道推送变化的数据。

处理流程大概是：客户端发起 TCP 连接后，先发一个 HEL（Hello）消息打招呼，服务端回 ACK（Acknowledge），握手完成后客户端会调用 OpenSecureChannel 建立安全通道，等通道建立完就可以 CreateSession 创建会话，最后 ActivateSession 完成激活。没有会话时，客户端虽然能连上通道，但无法读变量、写数据。

订阅则是更后面的东西：客户端建好会话后，可以再创建订阅，把感兴趣的变量加进去（MonitoredItem），服务端按采样周期检测变量变化并存入发布队列，等客户端发 Publish 请求拉取数据。这里最容易被初学者误解的就是：订阅数据的推送不是服务端主动推的，而是靠客户端周期性发 Publish 请求来“取”的。 服务端只是在每个 Publish 请求到达时把队列里的数据塞进响应返回。

我最初也犯过这个错，以为和 WebSocket 那样建个订阅就等着服务端推数据就行，结果调试了很久 UA Expert 都刷不出变化值。所以如果你只是做基础读写，订阅那一块可以往后放，优先把会话建立和数据读写跑通。

2.3 地址空间模型：这才是服务端真正的内功

说实话，协议编解码都只是“管道工”的活，真正的脑力活是信息模型。OPC UA 服务端本质上是一个节点库，客户端通过浏览、读写这些节点和外部世界交互。

每个节点都有一个节点 ID（NodeId），节点 ID 由命名空间索引（NamespaceIndex）和标识符构成。命名空间索引就是我们常说的“命名空间 0”（标准节点）和“命名空间 1”（应用自定义节点）。标准节点由 OPC 基金会预先定义好了，比如 ObjectsFolder 的 NodeId 是 85，TypesFolder 的 NodeId 是 86。我们自定义的变量、方法一般放在命名空间 1 里，NodeId 可以是整数标识符，比如 ns=1;i=1001。

节点之间靠“引用关系”连接，就像文件系统里文件夹和文件的关系。根节点下面有 ObjectsFolder、TypesFolder、ViewsFolder，ObjectsFolder 下面挂着真实设备，比如“温度传感器”“电机”等。客户端用 Browse 服务遍历这些节点，顺着引用关系一层层找下去。

信息模型不只是“数据结构”，它同时决定了客户端怎么展示、怎么写入。我实现的时候花了最多时间的是把真实设备的参数映射成节点树，不仅要考虑读写权限，还要考虑单位、工程值转换、报警状态等。如果你只做一个 Demo，可以先把一棵最简单的节点树搭起来：

• ObjectsFolder（ns=0;i=85）
• 对象“设备状态”（ns=1;i=1001）
• 变量“当前温度”（ns=1;i=1002，Parent 为设备状态）
• 方法“复位”（ns=1;i=1003，Parent 为设备状态）

这个模型足够用来跑通几乎全部基础功能。

3. 实操过程：从零手写最小可运行服务端

3.1 第一步：TCP 监听器与消息帧解析

服务端第一件事就是起一个 TCP 监听器。采用 .NET Framework 时我用的是 TcpListener，如果换成 .NET Core 可以用 Socket 或 SocketAsyncEventArgs，不过思路都一样：监听 4840 端口（OPC UA 默认端口），收到连接请求后进入异步读取循环。

读取时要注意粘包和半包问题。TCP 是字节流，没有消息边界，所以必须先积累到 8 字节消息头，解析出消息长度后再决定是否要把后面的数据一次收完。我封装了一个 OpcTcpFrame：

csharp复制public class OpcTcpFrame
{
    public string MessageType { get; set; }  // 3字节：HEL/OPN/MSG/CLO
    public byte ChunkType { get; set; }       // 1字节：F/C
    public uint MessageSize { get; set; }     // 4字节，大端还是小端要按规范来
    public uint ChannelId { get; set; }       // 4字节
    public byte[] Payload { get; set; }
}

public static OpcTcpFrame ParseFrame(byte[] buffer)
{
    var frame = new OpcTcpFrame();
    frame.MessageType = Encoding.ASCII.GetString(buffer, 0, 3);
    frame.ChunkType = buffer[3];
    // 注意：MessageSize 和 ChannelId 的字节序按 OPC UA 规范实现
    frame.MessageSize = BitConverter.ToUInt32(buffer, 4);
    frame.ChannelId = BitConverter.ToUInt32(buffer, 8);
    var payloadLength = (int)frame.MessageSize - 12;
    frame.Payload = new byte[payloadLength];
    Array.Copy(buffer, 12, frame.Payload, 0, payloadLength);
    return frame;
}

这里最容易踩的坑是消息长度计算。凡是不熟悉协议的人，拿到一个 OPC UA 包总会纠结 MessageSize 到底算哪一段。实际上它从消息头开始算，包括消息头本身。比如一个 Hello 包，总 message 大小是 12 字节消息头 + Hello 参数长度。你读出来还得补一个校验：如果 MessageSize < 12 或者 Payload 长度和剩余数据对不上，一定是解析错位了，需要把缓冲区重置重新对齐。

3.2 跨过客户端“连不上”的坎：Hello/ACK 握手

客户端连接后发来的第一条消息一定是 HEL。服务端要做的第一件事就是回应 ACK。这两个消息结构不复杂，但字段顺序错了或类型错了，UA Expert 直接提示“Handshake failed”。

Hello 消息体包含六个字段，依次是：

• 协议版本（UInt32）
• 接收缓冲区大小（UInt32）
• 发送缓冲区大小（UInt32）
• 最大消息大小（UInt32）
• 最大 chunk 数量（UInt32）
• 端点 URL（String）

服务端收到后必须返回 ACK，ACK 消息体和 Hello 一样也是六字段：协议版本、接收缓冲区大小、发送缓冲区大小、最大消息大小、最大 chunk 数量、端点 URL（服务器意图的字符串）。

缓冲区协商是很多人忽略的关键点。客户端说它接收缓冲区能放下 65536 字节，不代表服务端也一定要用这个值。服务端回复 ACK 里的接收缓冲区大小是告诉客户端“在所有后续消息里，我每个 chunk 最多接受多少字节”；发送缓冲区大小则是“我发出的每个 chunk 最大多少字节”。这两个值直接决定后面分片逻辑，服务端最小值就按收到的 Hello 里声明的值来回，通常能兼容所有客户端。

写握手响应时我的经验是先用一个最小响应把端点 URL 留空，然后再在后续的 GetEndpoints 服务里把真正的端点地址返回。

3.3 服务分发器与请求/响应对齐

OPC UA 服务端本质是一个请求/响应循环：收到 MSG 类型的消息后，解析请求头里的 RequestId，找出请求类型，执行对应服务函数，最后把 RequestId 原样带进响应消息返回。

这个机制和 HTTP 很像，也正因为如此，并发请求的匹配问题才那么重要。你的服务器可能在同一条通道上同时收到多个请求（尤其是订阅发布场景下，客户端会高频发 Publish 请求），不能简单地“来一个处理一个然后返回”，必须用 RequestId 作为关联键。我实现了一个请求管理器，在收到 MSG 时解析出 RequestId 和服务类型（TypeId），将处理任务放进线程池，完成后按 RequestId 回调。

基本服务类型我实现了七个：GetEndpoints、OpenSecureChannel、CloseSecureChannel、CreateSession、ActivateSession、Read、Write、Browse。到这一步，一个“能连、能读、能写”的极简服务端基本就成型了。

4. 实操过程：让服务端真正“有内容”可读

4.1 地址空间与数据变量的实现方式

地址空间是整个服务端的中枢，我用了一个字典来保存节点：

csharp复制public class AddressSpace
{
    private readonly Dictionary<NodeId, Node> _nodes = new Dictionary<NodeId, Node>();
    private readonly List<Reference> _references = new List<Reference>();

    public static readonly NodeId ObjectsFolder = new NodeId(0, 85);

    public void AddNode(Node node)
    {
        _nodes[node.NodeId] = node;
    }

    public void AddReference(Reference reference)
    {
        _references.Add(reference);
    }

    public Node FindNode(NodeId nodeId)
    {
        _nodes.TryGetValue(nodeId, out var node);
        return node;
    }

    public IEnumerable<Reference> FindReferences(NodeId sourceId, bool isForward = true)
    {
        return _references.Where(r => r.SourceId == sourceId && r.IsForward == isForward);
    }
}

节点的属性除了 NodeId 之外，最重要的是 BrowseName、DisplayName、DataType、Value。实际工业场景里，变量值往往不是固定值，而是从 PLC、Modbus RTU 或动态计算引擎里取出来的。我后来抽象了一个 IVariableSource 接口：

csharp复制public interface IVariableSource
{
    object ReadValue(NodeId nodeId);
}

这样地址空间只管节点定义，不关心数据从哪来。客户端读一个变量时，服务层调用 ReadValue 从外部数据源取实时值，这才是工业现场的真实形态。

至于 NodeId，我实现了字符串和整数两种标识符。调试时整数标识符更好用，因为 UA Expert 的地址空间窗口里能直接显示出 ns=1;i=1001 这种地址，定位问题更直观。

4.2 处理 Browse：让客户端能找到你的节点

服务端建好了节点树，客户端能不能看到就是 Browse 服务的事了。UA Expert 连接上服务端第一件事就是从左边的“地址空间”里浏览节点目录。如果 Browse 实现不对，客户端界面就是一片空白。

Browse 请求的核心参数是 NodeId（要浏览的源节点）和 NodeClassMask（过滤哪些类型的节点），响应里要返回的是目标节点的引用列表。我第一次实现时错误地把“引用”和“子节点”混为一谈，结果 Browse 时返回了大量重复节点。

后来才搞明白：浏览操作遍历的是源节点的正向引用列表，每个引用有四个要素：SourceNodeId、ReferenceTypeId、TargetNodeId、IsForward。客户端会沿 IsForward=true 的引用找到目标节点，再一层层展开。我维护引用列表时同时考虑反向引用，所以返回前一定要把 IsForward 字段设置正确，否则会出现目录树“循环套娃”。

还有个细节：UA Expert 默认给 Browse 请求传的节点是名称为空字符串的 NodeId（等价于从 RootFolder 开始浏览）。如果你的服务端没实现 RootFolder 的浏览，客户端就什么都看不到。

4.3 读写方法：让数据真正流动起来

OPC UA 的写操作最容易被忽略的地方是数据类型的匹配。客户端写一个温度值时，如果它传的是 Double 而服务端变量声明是 Float，就会写失败。我最初的实现里直接按请求里的类型强转，结果遇到 UA Expert 客户端优化手段时丢了不少数据。

正确做法是：写入时校验节点声明的数据类型和请求类型，再通过 Convert.ChangeType 转换。这个转换过程看起来是小问题，但表现给用户的故障是“写进去了但值不对”，排查起来特别费时间。

方法（Method）的调用相对独立。OPC UA 方法定义在节点上，需要实现的是输入参数和输出参数的数组。UA Expert 调用方法时会把参数列表序列化发过来，服务端解析后按方法签名计算，再把结果写入输出参数。我实现的一个简单“复位”方法就是：把变量值重置为初始值，并返回一个布尔值表示复位状态。

5. 真实踩坑记录：这些坑官方文档不会写清楚

5.1 客户端能连上但读不到任何数据

这是我调试时遇到最多的现象。UA Expert 连接提示成功，但右边的数据面板始终没有任何内容。排查到最后，问题往往出在 Browse 或节点属性上。

具体有两种情况。

第一种：地址空间分支没接对。如果自定义节点没有正确地挂在 ObjectsFolder 下面，客户端从 RootFolder 一层层浏览时就找不到那部分分支。我在自定义命名空间漂移时踩过这个坑，节点 ID 用了 ns=1;i=1001，但忘了给 ObjectsFolder 和这个节点之间加 Organizes 引用，UA Expert 自然看不见。

第二种：创建会话时的端点返回没对齐。有些客户端连接时会去访问 GetEndpoints 拿到可用端点列表，然后在 CreateSession 时带上端点 URL。如果你的 GetEndpoints 返回的端点 URL 和自己在 TCP 层监听的地址不一致，客户端可能完成了“握手”却无法真正建立服务会话。我后来把端点地址写死成和监听地址一致，问题马上消失。

5.2 会话被“踢下线”：非活动超时与续约机制

OPC UA 会话默认有一个非活动超时时间，客户端如果长时间不发请求，服务端口会关闭会话。这是合理的安全机制，但在调试订阅时特别容易误伤：你创建完订阅后以为数据会自动推过来，实际上客户端要周期性发 Publish，否则会话超时后连着订阅一起销毁。

我后来在服务端把会话超时时间默认设成 5 分钟，同时在客户端测试脚本里每隔 30 秒发一次“会话保持心跳”，这才解决了调试时反复被踢下线的问题。

另一个细节是 SecureChannel 的 Token 续期。OpenSecureChannel 时客户端会带一个 RequestedLifetime，单位是毫秒。服务端返回的 RequestedLifetime 需要比实际 Token 生命周期小，否则客户端会过早地认为令牌失效而重新申请。我第一版直接返回客户端传来的原值，结果 UA Expert 隔段时间就自动重建通道并重新激活会话，日志刷屏。

csharp复制// 返回比请求值略短的生命期
response.RequestedLifetime = Math.Min(request.RequestedLifetime, 3600000);

5.3 消息分片：超过缓冲区大小就抓狂

OPC UA 客户端和服务端之间传输消息时可以分片。一旦要读写超大文档（例如读取包含几千个节点的数据块），响应的消息体可能超过缓冲区大小，必须拆成多个 Chunk 发送。我最初偷懒，不管实际大小一次性把响应发出去，结果客户端要么直接报错，要么只截取前半段数据。

正确做法的核心逻辑：比较响应的实际消息长度和服务端声明的发送缓冲区大小，如果超过，就要按 chunk 边界把消息拆开，第一个 chunk 发 Type=C，最后一个 chunk 发 Type=F。中间 chunk 的 Sequence Number 必须连续，不能让客户端抓到中断的流。

分片实现时我踩过一个大坑：分片后的消息头里 MessageSize 是当前这个 chunk 的大小，而不是整个消息的大小。很多教程把 MessageSize 理解成“总消息长度”，这是错误的。我最初也这么写，结果客户端收到第一个 chunk 后直接报错，根本等不到下一个 chunk。

6. 互操作性测试：我跟 UA Expert 死磕的那些天

6.1 建立测试环境

写协议栈最大的风险是“自说自话：自己的客户端连自己的服务端通畅，碰到第三方工具就各种问题。我在服务端完成核心功能后，专门搭了一套互操作测试环境。

测试客户端我用的是 OPC UA 官方社区常用的互操作工具 UA Expert（由 OPC 基金会维护，跨平台，免费）。UA Expert 的价值在于它对协议实现非常挑剔，协议哪里少个字段、多两个字节、顺序不对，它直接报错或超时，不会像自写客户端一样“帮”你修正。

测试步骤并不复杂：先把服务端跑起来，打开 UA Expert，添加 OPC UA 服务器地址 opc.tcp://127.0.0.1:4840，然后配置用户连接模式（匿名），点连接就完事。

第一次连接时我把抓包工具打开，同时记录了服务端的日志输出，一旦 UA Expert 报错，立马对照日志抓包。这个过程很痛苦，但也最快逼着我把不规范的字节处理全部修正。

6.2 检查清单：哪些测试必须过

我的测试清单按优先级分为三档：

必过的功能项：

• 连接握手（HEL/ACK），确认地址可见
• 浏览根节点、ObjectsFolder、自定义命名空间节点
• 读取一个变量的当前值
• 写入一个变量的值并回读验证
• 断开连接后服务端能自动释放资源

应该过的功能项：

• 创建订阅，监控变量变化（变化值能被 UA Expert 的“数据监视”面板刷出来）
• 调用方法，输入输出参数正常
• 多个客户端同时连接，各自浏览读写互不干扰
• 重连后会话身份仍然有效（等服务端实现会话缓存）

进阶的功能项：

• 大数据量浏览不崩、不分片错误
• 长时间运行后内存消耗稳定
• 并发读写压力下响应时延正常

我在第一次通过“必过项”后，就顺手把“订阅监控变化”补上了。这里又踩了一个印象深刻的坑：UA Expert 的数据监视面板默认的采样周期是 1000 毫秒，但我的服务端变量值只有在外部数据源变化时才会更新。如果不主动制造变量变化，面板上永远不会出现数据。所以测试时要在外部模拟数据源里持续修改值，或者做一个自动变化的自增计数器。

UA Expert 的“沙盘”模式也值得一提。它会把浏览到的节点展示成树形结构，你可以右键节点执行 Read、Write、HistoricalRead。这比我自己写的独立测试程序好用多了，很多边界情况它都能暴露出来。比如它会把 Browse 请求里带上 RequestedMaxReferencesPerNode 这个字段，值为 0 时表示“无限制”，如果服务端没有正确处理，返回结果就会被截断。

6.3 自己写一个最小客户端回连验证

除了 UA Expert，我还写了一个几十行的最小 C# 客户端用来做快速回归。这个客户端不追求完整实现，只验证“读一条变量”的动作是否正常。好处是调试太方便了——UA Expert 的 UI 偶尔隐性地吞掉错误，但自己写的客户端能直接把收到的原始数据打印出来。

csharp复制using System;
using System.Net.Sockets;
using System.Text;

class QuickCheckClient
{
    static void Main()
    {
        while (true)
        {
            Console.Write("请输入要读的节点ID（如 ns=1;i=1001）：");
            var input = Console.ReadLine();
            if (string.IsNullOrWhiteSpace(input)) break;

            using (var client = new TcpClient("127.0.0.1", 4840))
            {
                var stream = client.GetStream();
                // 此处省略完整的 OPC UA 二进制报文构造过程
                // 关键是把 ReadRequest 的 TypeId 设为正确值
                // 并把 RequestHeader 里的 SessionId 填成已建立会话
                Console.WriteLine("发送 ReadRequest: " + input);
                // 接收并打印原始响应
                var buffer = new byte[4096];
                int read = stream.Read(buffer, 0, buffer.Length);
                Console.WriteLine("收到 " + read + " 字节");
                Console.WriteLine(Encoding.ASCII.GetString(buffer, 0, Math.Min(read, 128)));
            }
        }
    }
}

这个小工具虽然丑，但整个协议栈每改一次，我都先跑一遍它，确认基本读写没问题，再开 UA Expert 做完整回归。这样能显著缩短问题定位时间。

7. 什么时候该收手：纯手写不等于最优解

写到这里，我还是想泼一盆冷水：如果你不是在研究协议实现，而是要在生产项目里快速交付，或者你的团队没有长期维护协议栈的人力，直接用成熟库是更理性的选择。 纯手写一次打通很容易，但后续维护成本很高，因为 OPC UA 的规范迭代是持续的，新版客户端可能会用到旧服务端不支持的特性。

我个人判断“该不该手写”的三个标准：

• 目标运行环境是不是溃疡式的客户定制环境，第三方库的部署、授权、审计是否过不了关。
• 团队有没有一个月以上的时间做协议兼容测试，尤其是跨厂商客户端互测。
• 是否需要完全控制协议栈内部细节，比如特殊信息模型、特殊安全策略、特殊传输映射。

如果这三个条件一个都不满足，建议用成熟协议栈，把精力花在业务信息模型设计上。即便我用纯代码实现了这个服务端，也不得不承认，对于大多数常规场景，成熟库比手写方案稳定得多。

但这并不意味着手写没有价值。写完这个服务端后，我对 OPC UA 的认识上了一个台阶，处理客户端兼容问题、性能瓶颈时的效率提高了不少。尤其是理解地址空间设计和订阅机制后，即使后来切换到成熟协议栈，也再没出现“只见参数不知道怎么调”的窘境。

最后分享一个实际体会：如果一定要手写，别贪大求全第一版就做安全加密策略。先把 SecurityPolicy None、匿名会话、基础读写、单客户端浏览这条最小通路跑通，让 UA Expert 能连上、能看到节点、能读到数，再一步步往上补安全、认证、订阅、多会话。这样每个里程碑都可测试、可交付，也不会被协议规范的庞大细节拖垮。说到底，OPC UA 协议栈是一个靠字节数拼起来的精密系统，能跑起来的版本永远比规划完美的版本更值钱。