4. OPC UA 地址空间：从概念到落地
地址空间，说白了就是 OPC UA 服务器的“家底”。你想想看，一个服务器里有哪些设备、哪些变量、哪些报警，总得有个地方把它们组织起来吧？这个地方就是地址空间。我刚开始接触 OPC UA 时，总觉得这东西不就是个树形结构嘛，跟文件系统差不多。后来真做项目了才发现，里面的门道可不少。
4.1 地址空间的核心概念
地址空间不是简单的数据集合。它是一个面向对象的、网络化的信息模型。每个节点（Node）都有唯一的标识符——NodeId。节点之间通过引用（Reference）连接，形成一张巨大的图。
关键点：地址空间中的节点类型是固定的，一共 8 种。但你可以通过类型定义（TypeDefinition）无限扩展自己的对象类型。
我记得第一次搭建地址空间时，犯了个低级错误：把两个不同设备的温度变量用了同一个 NodeId。结果客户端一浏览，两个温度值互相覆盖，查了半天才找到原因。所以，NodeId 的唯一性是地址空间的第一条铁律。
4.2 根节点与组织方式
地址空间的组织方式，我习惯用“三根柱子”来理解：
- Objects 文件夹：存放所有实例化对象，比如设备、控制器、传感器。
- Types 文件夹：存放所有类型定义，包括对象类型、变量类型、数据类型。
- Views 文件夹：存放视图，用于过滤和简化地址空间的浏览。
这三根柱子都挂在 Root 节点下面。Root 节点是地址空间的入口，它的 NodeId 是 i=84。嗯，这个数字我记了很久，因为调试时经常要用到。
小技巧：如果你在写服务器代码时不知道从哪里开始构建地址空间，就从 Root 节点开始，先挂 Objects 和 Types 两个子节点。这是最稳妥的起步方式。
下面这张图展示了地址空间的顶层结构：
4.3 浏览（Browse）与查询（Query）
地址空间建好了，客户端怎么找到它想要的数据？两种方式：浏览和查询。
4.3.1 浏览（Browse）
浏览就像你在文件系统里一层层点开文件夹。客户端从某个起始节点（通常是 Root 或 Objects）开始，沿着引用关系往下走。每次 Browse 请求返回当前节点的所有子节点。
我做过一个项目，现场有 2000 多个设备，每个设备下面又有几十个变量。客户端如果从头到尾浏览一遍，光网络开销就够呛。后来我用了 Browse 的过滤功能，只返回特定类型的节点，效率提升了好几倍。
实战建议：Browse 请求时一定要设置 MaxReferencesPerNode 参数。默认值通常是 0（不限），但生产环境中建议设为 100-500，避免一次返回太多数据导致内存溢出。
Browse 请求的核心参数：
| 参数 | 说明 | 我的建议 |
|---|---|---|
| NodeId | 起始节点的标识符 | 通常从 Objects 开始 |
| BrowseDirection | 浏览方向（正向/反向/双向） | 默认正向即可 |
| ReferenceTypeId | 过滤特定引用类型 | 常用 Organizes、HasComponent |
| NodeClassMask | 过滤节点类型 | 只返回 Object 或 Variable |
| MaxReferencesPerNode | 单次返回的最大引用数 | 建议 100-500 |
4.3.2 查询（Query）
查询就高级多了。它允许客户端用类似 SQL 的方式，一次性从地址空间中筛选出符合条件的节点。比如：“找出所有温度大于 100 度的传感器”。
不过说实话，我在实际项目中很少用 Query。为什么？因为很多 OPC UA 服务器对 Query 的支持并不完整。我曾经在一个项目中尝试用 Query 查询历史数据，结果服务器直接返回了 BadNotSupported。所以，如果你不确定服务器是否支持 Query，先用 Browse 兜底。
注意：Query 操作对服务器性能消耗较大。如果地址空间中有上万个节点，一次复杂的 Query 可能导致服务器响应延迟。建议在非实时场景下使用。
4.4 地址空间的持久化
地址空间是运行时构建的，但服务器重启后怎么办？总不能每次都重新建一遍吧？这就涉及到持久化的问题。
我见过三种常见的持久化方式：
- 文件存储：把地址空间导出为 XML 或二进制文件。启动时加载。
- 数据库存储：用 SQLite、MySQL 等数据库保存节点和引用信息。
- 代码硬编码：在服务器代码里直接写死地址空间结构。启动时自动构建。
我个人最推荐文件存储 + 代码硬编码的组合方式。核心结构用代码构建，动态数据（比如设备列表）从文件加载。这样既保证了启动速度，又保留了灵活性。
经验之谈：我曾经接手过一个项目，地址空间完全用代码硬编码，但设备列表是动态变化的。每次增加设备都要改代码、重新编译、重启服务器。后来我改成从 XML 文件加载设备列表，问题就解决了。所以，静态结构用代码，动态数据用文件。
下面是一个简单的地址空间持久化 XML 示例：
<!-- 地址空间持久化示例 -->
<UANodeSet xmlns="http://opcfoundation.org/UA/2011/03/UANodeSet.xsd">
<UAVariable NodeId="ns=2;i=100" BrowseName="2:Temperature">
<DisplayName>温度</DisplayName>
<DataType>i=6</DataType> <!-- Double -->
<Value>
<uax:Double xmlns:uax="http://opcfoundation.org/UA/2008/02/Types.xsd">25.5</uax:Double>
</Value>
</UAVariable>
<UAObject NodeId="ns=2;i=200" BrowseName="2:Device1">
<DisplayName>设备1</DisplayName>
<References>
<Reference ReferenceType="i=35" IsForward="false">i=85</Reference> <!-- 挂到 Objects 下 -->
<Reference ReferenceType="i=47">ns=2;i=100</Reference> <!-- 包含温度变量 -->
</References>
</UAObject>
</UANodeSet>嗯，这里要注意：持久化时一定要保存 NodeId 的命名空间索引（NamespaceIndex）。我见过有人只保存了数字 ID，结果加载时命名空间对不上，所有节点都变成了孤儿节点。
避坑指南：我曾经在持久化时忘记保存 NodeClass 属性，结果加载后所有节点都变成了 Object，变量节点无法读写。所以，持久化时要保存完整的节点属性，包括 NodeClass、BrowseName、DisplayName、DataType 等。
最后总结一下地址空间的几个要点：
- 地址空间是 OPC UA 服务器的核心，所有数据都在这里组织
- 根节点是 Root（i=84），下面挂 Objects、Types、Views 三个子节点
- 浏览（Browse）是客户端获取数据的主要方式，查询（Query）是高级筛选
- 持久化推荐“静态代码 + 动态文件”的组合方式
- NodeId 的唯一性和命名空间索引的正确性是常见坑点
地址空间这块内容，说难不难，说简单也不简单。关键是要动手搭一遍。我建议你找个开源 OPC UA 服务器（比如 open62541 或 UA-.NETStandard），自己写个简单的地址空间，然后拿 UA Expert 去浏览一下。踩过几个坑之后，你就真正理解了。