这类系统多半要落到不联外网的内网里。下面是选型阶段真正要拍板的几件事、 完全离线环境必须过掉的四道关，以及从部署到验收的清单。写的是取舍依据，不是产品说明。
安全工器具管理系统的数据有两个特点：一是跟人绑定（谁在什么时候借走了哪一件、由谁核验身份）， 二是跟安全责任绑定（试验周期、报废状态、到期预警）。这两类数据一旦出事， 要能自证当时的记录是什么样。
再加上现场的网络条件：变电站、检修车间、电厂库房这类场景，内网往往物理隔离， 不联外网也不允许联。有些单位即使有外网，也有明确的「业务数据不得出内网」要求。 所以这不是「要不要上云」的偏好问题，而是交付前置条件。
如果你在选型阶段，问供应商的第一个问题不应该是「有没有云版」， 而是「完全无外网的环境下，安装、授权、升级、备份这四件事分别怎么做」。 能当场答出这四项的，才是做过内网交付的。
私有化不等于「一套架构走天下」。实际交付里按规模分三档，选错档位会出现两种浪费： 小场景上了集群，大场景用单机扛。
| 形态 | 典型场景 | 跑在哪 | 优点 | 要注意 |
|---|---|---|---|---|
| 单机桌面版 | 单个班组、一间库房，1～2 台操作终端 | 一台 Windows 或 Linux 工作站（本机带数据库） | 部署最简单，一台机器装完即用，不依赖网络 | 多终端无法协同；机器故障即业务中断，需本地备份 |
| 局域网服务器版 | 一个库房配多个终端，或几个库房要统一台账 | 内网一台服务器 + 桌面工作站 / 浏览器 / PDA | 三端共用一套数据，现场与后台一致；集中备份 | 服务器要做资源与磁盘规划；终端与服务器时钟要一致 |
| 容器化全栈 | 要标准化交付、便于复制到多个现场 | 内网 Linux + 容器运行时，一套编排拉起全部组件 | 环境一致、升级回滚干净、便于批量复制 | 镜像要能离线导入；旧内核与旧容器版本要提前确认 |
三条经验性的判断：
顺带一提，服务器版并不排斥桌面端 —— 反过来，成熟的形态通常是 服务器跑业务与数据库、桌面端做现场操作、浏览器做后台管理、PDA 做移动盘点， 四者共用同一套业务规则。这样现场操作和办公室看到的数是同一个数，不会出现两本账。
这一节是整个方案里最容易在验收前夜翻车的地方。「支持私有化部署」这句话谁都说得出口， 但真正隔离的内网会挨个暴露下面四个依赖。
很多部署方式表面上是「一个安装包」，运行时却要去公共源拉依赖（语言运行时、数据库、 容器基础镜像、前端资源）。内网一断，卡在第一步。
判断方法很简单：把安装介质拷到一台完全断网的机器上，从头装一遍。 装不上就不是离线包。合格的形态是自包含的 —— 运行时、数据库、静态资源全在包里。
如果软件的授权是「启动时连授权服务器校验」，内网里必然用不了。 内网交付要用离线注册码：
用非对称签名（如 Ed25519）而不是「按规则算个校验位」的好处是： 签发能力只在软件方手里，注册码可以公开传输也不会被伪造成别的机器码。 注册文件通常还会混入机器特征做二次绑定，防止一份注册码在多台机器上复制使用。
机器码必须在同一台机器上每次算出来都一样，否则重启、加网卡、装 Docker 都会让授权失效。
最常见的事故是：机器码按网卡名排序取第一块网卡，而装完 Docker 后多出来的
docker0 网桥排到了物理网卡前面 —— 机器码变了，注册失效，现场表现为
「重启一次就要重新注册」。
正确做法是只认物理网卡（系统里带 device 目录项的那些网络接口），
并在签发时把绑定值写进注册文件里钉死，而不是每次启动重新计算。
内网没法「在线上拉个新版本」。可行的升级形态是覆盖式离线升级包： 把程序与依赖整体打包成一个归档，内网里解压覆盖到原目录、重启服务即可。 它的好处是升级过程不碰数据目录、也不需要外网，回滚就是把备份的目录解回去。
两个细节值得在验收时确认：一是升级包不带私钥与签发工具（这些只应留在软件方一侧， 随包发出去等于把授权体系一起送人）；二是升级后配置文件与数据目录不被覆盖， 否则一次升级会把现场参数清零。
浏览器管理端如果引用公共 CDN 上的字体、脚本库或图标资源，内网打开会长时间白屏等超时。 所有前端资源必须随部署包一起落在本地，由内网服务器自己发。 这一条在演示环境里完全看不出来 —— 演示时有外网，怎么都好使。
① 断网机器上能否装完 → ② 断网后能否授权激活 → ③ 断网后能否升级 → ④ 断网后浏览器端能否完整渲染。四项全过，才算真的能离线交付。 建议把这四项直接写进采购合同的验收条款。
这套系统的负载特征很明确：并发低、写入量小、但要长时间不间断运行。 它不像面向公众的互联网应用有流量峰值，所以配置估算的思路完全不同 —— 看的是稳定性与磁盘，不是算力。
| 资源 | 典型规模 | 说明 |
|---|---|---|
| CPU | 2 核 | 业务请求量很小，瓶颈几乎从不在这里 |
| 内存 | 4 GB 起 | 主要消耗在数据库缓冲；内存紧张时优先压数据库参数，而不是砍功能 |
| 系统盘 | 40 GB+ | 程序与数据库 |
| 数据盘 | 按场景估 | 台账与截图增长平缓；视频录像是大头，按摄像头路数与保留天数单独算 |
| 时钟 | 内网 NTP 或手工对齐 | 多终端时间不一致会让借还记录的顺序错乱 |
几个容易忽略的点：
私有化部署的核心承诺是数据落在用户自己的服务器上：数据库随部署包一并安装， 业务数据不出内网，也不经过任何第三方云端。这一点在选型时值得让供应商明确写进方案 —— 有些「私有化」实际是把数据同步到厂商云端再回传，内网一断就废。
备份建议做两层，都在内网存储上完成：
还有一件常被忽略的事：备份要演练恢复。只导出不恢复， 等于没有备份 —— 真正的坑是备份文件本身损坏或权限不对， 而这些只有在恢复演练时才会暴露。建议上线后先做一次完整的「删库重建」演练。
私有化部署的工作量有一大半在硬件对接上。以下是这类系统通常会碰到的设备， 以及每类需要在选型阶段确认的问题：
| 设备 | 用途 | 对接前要确认的 |
|---|---|---|
| RFID 读写器（读写头） | 标签识别、发卡、盘点、门控联动 | 是否提供可离线部署的 SDK；同步/异步读模式；GPI/GPO 是否开放 |
| RFID 电子标签 / 卡片 | 工器具逐件唯一标识 | 是否可写 TID / 用户区；写卡时长度与格式约定 |
| 人脸识别设备 | 借还环节身份核验 | USB 摄像头方案还是网口一体机；离线人脸库存储位置；回调地址能否配到内网 |
| 标签打印机 | 发卡时打印标签 | 指令集（如 TSPL 系）与 DPI；驱动能否在目标系统上离线安装 |
| NVR / 摄像头 | 取还环节的视频留痕 | 是否支持 RTSP 取流；编码格式；录像保留天数 |
| 温湿度传感器 | 库房环境记录 | 通信协议（如 Modbus 系）与寄存器地址表 |
| 门禁 / 门控 | 开门触发扫描、关门自动提交 | GPI 触发语义（边沿还是电平）；单门还是双门 |
它意味着软件侧按通用接口协议对接，已有工具柜或读写设备可以直接复用， 不必为了上系统而整套换硬件。但要注意，能否复用取决于柜体是否开放读写器与门控接口 （GPI/GPO）—— 硬件能读卡，不等于软件能直接调它的读写与门控。 这一项要在选型阶段就确认，不要等到进场施工时才发现柜门打不开。
如果你是属于硬件那一侧的（工具柜厂家、集成商）， 软硬之间的分工与接口该怎么划，另写了一篇：工具柜厂家想配一套管理软件，找谁合作。
建议直接拿这份清单作为验收依据，逐项在断网状态下验证：
下面这些都是现场发生过、且在演示环境里绝对发现不了的问题，列出来供选型与验收时对照：
可以，但要同时解决四件事：安装包不依赖外网下载、授权不依赖在线校验、 升级包可在内网落地、前端资源不依赖公共 CDN。四项都做成离线形态后， 系统才能在没有外网的环境里长期运行。建议直接把「断网机器上装一遍」写进验收条款。
用离线注册码：部署机器上生成机器码，软件方据此用私钥签发一段签名注册码， 拷回内网导入、本地验签通过即激活，全程不需要联网。 用非对称签名（如 Ed25519）的好处是签发能力只在软件方手里， 注册码可以公开传输而不担心被伪造成别的机器码。
如果机器码是按网卡名排序取第一块网卡的 MAC，安装 Docker 后多出来的
docker0 网桥可能排到物理网卡前面，机器码随之漂移、注册失效。
稳妥做法是只认物理网卡，并在注册文件里把绑定值钉死，
避免每次启动重新计算。
不高。负载特征是并发低、数据量小、长时间运行，2 核 4G 通常够用。 真正需要规划的是磁盘（日志、截图、视频录像会持续增长）与数据库内存参数， 不是 CPU 核心数。
多数情况可以。软件按通用接口协议对接读写器与人脸设备，不绑定单一硬件品牌， 已有设备可直接复用。前提是柜体开放读写与门控接口（GPI/GPO）—— 这一项要在选型阶段确认，别等进场施工才发现柜门打不开。
用覆盖式离线升级包：程序与依赖整体打包，内网解压覆盖原目录再重启服务。 升级包不碰数据目录与配置文件，回滚就是把备份目录解回去。 另外升级包里不应包含私钥与签发工具。
数据全部落在用户自己的服务器上，数据库随部署包安装，不经过第三方云端。 备份做两层：数据库按日导出加保留周期轮转（恢复粒度细）， 数据目录定期快照（整机故障后重建快）。两者都放内网存储，并且要演练恢复。
不一定。规模小可以只在一台 Windows 工作站上跑单机版；需要多终端协同时再上局域网服务器版。 服务器侧 Linux 更常见（占用低、便于做成离线包与容器镜像）， 桌面工作站侧则常需要同时支持 Windows 与 Linux。