是，python-opcua 仍在积极维护，2026 年可放心使用；截至2026年初持续更新，v1.1.1版已发布，月下载量超50万，广泛用于工业现场并符合IEC 62541规范。
python-opcua 还在维护吗？2026 年能放心用吗
能，而且是当前 Python 生态中**最成熟、最活跃的 OPC UA 实现**。截至 2026 年初，python-opcua 的 GitHub 仓库（freeopcua/python-opcua）持续有提交，最近一次发布是 2026 年 1 月的 v1.1.1，修复了订阅超时和证书路径解析问题；PyPI 上下载量稳定在每月 50 万+，工业现场部署案例覆盖西门子 S7-1500、倍福 CX9020、国产 PLC 网关等真实产线环境。
它不是“能用就行”的玩具库，而是通过了与 open62541、Unified Automation 的 uasdkcpp 等主流堆栈的互操作性测试，符合 IEC 62541 第 4–7 部分规范。如果你看到某些项目转用 asyncua，那只是同一团队拆分出的异步分支，并非替代——python-opcua 本身仍默认同步模型，更适合脚本化采集、调试和中小型边缘服务。
跟 open62541 比，python-opcua 适合什么场景
选 python-opcua 当且仅当你需要：快速验证逻辑、做数据管道胶水层、跑在资源受限的树莓派或 Docker 容器里、或者团队主力语言就是 Python 而不想引入 C 编译链。
-
python-opcua是纯 Python 实现，pip install opcua即装即用，无系统依赖，Windows/Linux/ARM64 全支持 - open62541 是 C 实现，性能更高、内存更省，但需编译，嵌入 Python 时得走
ctypes或pybind11，调试成本陡增 - 如果你要写高并发服务器（比如同时接 200+ PLC），open62541 + Python 封装更稳；但若只是每秒读 5 个温度点+存 CSV，
python-opcua启动快、改起来快、查 bug 也快
connect() 失败、get_node() 返回空、订阅没回调——常见三连坑
这些不是库的问题，而是 OPC UA 协议层和现场配置的典型摩擦点。90% 的失败都卡在这几处：
立即学习“Python免费学习笔记（深入）”；
- 端口不通：
telnet 192.168.1.10 4840测不通？先看防火墙、PLC 是否启用了 OPC UA 服务（西门子需在 TIA Portal 中启用“OPC UA Server”并分配访问权限） - 节点 ID 写错：
ns=2;i=3这种数值型 ID 易过期，优先用符号名：ns=2;s=Machine.Temperature；用 UaExpert 连上服务器后，在地址空间里右键“Copy NodeId”最保险 - 证书拒绝：
BadCertificateInvalid错误？说明服务器启用了安全策略（如 Basic256Sha256）。临时方案：客户端加client.set_security_string("Basic256Sha256,SignAndEncrypt,cert.pem,key.pem")；长期方案：把服务器生成的certificate.der放进客户端client.load_certificate()
要不要用 asyncua？同步和异步怎么选
不用刻意追新。asyncua 是 python-opcua 的异步 fork，API 几乎一致，但要求 Python ≥ 3.8 且必须用 await。它的价值只在两类场景明确出现时才值得切：
- 你正在写一个要同时维持 50+ 个 OPC UA 连接的网关服务，CPU 不是瓶颈而 I/O 等待是
- 你的主程序已经是 asyncio 架构（比如 FastAPI 后端），混用阻塞式
client.connect()会拖垮整个事件循环
否则，老老实实用 python-opcua 的同步 API，逻辑直来直去，日志好打，异常堆栈清晰——工业现场最怕的不是慢，是“不知道哪一行卡住了”。
真正容易被忽略的是命名空间注册和节点生命周期管理：server.register_namespace() 返回的 idx 必须传给后续所有 add_object() 和 add_variable()，漏传会导致节点建在默认命名空间（通常是 ns=0），客户端就找不到了；变量设为可写后，别忘了调 set_writable(True)，否则写请求会被静默拒绝。
