门禁系统断网还能用吗：脱机刷卡、权限缓存与数据补传机制

门禁系统断网了还能不能开门，答案看权限名单存在哪。靠谱的脱机模式是权限提前下发到控制器本地，终端在本地完成刷脸、刷卡、密码比对，断网时照常放行，通行记录先缓存、网络恢复后自动补传；反过来，权限只存在云端、断网就转圈等待的系统，网络一断门禁就瘫痪。选门禁先问三个数：本地人员容量、卡片容量、事件容量各是多少，再确认补传机制。

脱机运行靠什么支撑

现代门禁普遍采用云边协同架构，云端管授权、端侧做验证，两条腿分工明确：

核心逻辑是权限的验证在本地完成，不依赖实时网络。人脸特征提取与比对、刷卡密钥校验都在设备本地执行，断网期间只要名单已经同步过，通行就不受影响。

容量指标怎么读

脱机能力靠本地存储撑起来，选型时把这几项容量数字问清楚：

事件记录容量比人员容量更容易被忽视。断网时间越长、通行越频繁，本地事件占用越快，容量满了之后老记录可能被覆盖，补传就补不全，追溯的时候缺数据。

断网时哪些功能还在、哪些失效

按功能逐项核对，断网状态下的可用性一目了然：

这里有个常见的坑：断网期间做了开卡或删卡操作，人员以为已经生效，实际权限要等联网同步后才落地。放假前批量调整权限，要在放假前联网完成同步，别拖到假期当天。

补传与数据一致性

离线记录怎么回到云端，体现方案的成熟度：

1. 离线事件在本地带时间戳存储，网络恢复后按断点续传方式批量同步到平台。
2. 平台按时间戳合并记录，避免恢复瞬间产生大量实时事件挤掉离线记录。
3. 断网期间积压的管理指令（开卡、删卡、时段调整）在恢复后同步下发，权限状态与云端收敛一致。
4. 多控制器场景要保证时钟同步（NTP 校时），否则补传记录时间错乱，追溯失去意义。
5. 权限冲突按后写入者优先合并，防止旧名单覆盖新名单。

补传机制可以在验收时实测：断开网络造一批通行记录，恢复后看平台是否完整收到。

脱机安全的漏洞要堵

脱机好用，不等于可以放松警惕，三个漏洞要提前堵上：

1. 卡片安全：老一代 M1 卡采用的加密算法多年前已被破解，卡片可被克隆仿制。重要场所换用 CPU 卡等加密卡，杜绝复制风险。
2. 权限回收延迟：断网期间名单无法实时更新，离职、退租人员的权限要提前在云端吊销并保证联网同步，别让失效凭证继续开门。
3. 断电问题：断网不影响供电，但断电会让控制器停摆。控制器接后备电源，电锁的常开常闭策略按消防联动要求配置，确保断电时逃生通道方向能开。

验收时怎么测脱机

脱机能力不能只看说明书，按下面的步骤现场实测：

1. 提前批量下发授权名单，确认同步完成，人员、卡片数量与平台一致。
2. 断开控制器的上行网络，逐项测试刷卡、刷脸、密码认证开门，确认本地放行正常。
3. 断网状态下新增一张临时卡并尝试开门，确认权限未同步、无法通行。
4. 恢复网络，核对断网期间的通行记录是否完整补传，数量与本地缓存一致。
5. 切断供电测试后备电源投入，确认电锁按预案动作、控制器数据不丢失。
6. 连续做多天断网模拟，观察事件容量占用与记录覆盖情况。

门禁的本质是把「谁在什么时间能进哪扇门」这件事管住，网络只是传输通道，不该成为安全链路里的单点。权限本地化、记录可补传、断电有预案，这套门禁才经得起突发状况的检验。

TL;DR 检查清单

1. 权限要下到控制器本地，断网时本地验证放行。
2. 选型核对人员、卡片、事件三项容量，事件容量容易被忽视。
3. 断网期间开卡删卡不生效，假期前提前联网同步。
4. 离线记录带时间戳断点续传，平台按时间合并。
5. 重要场所用加密卡，防卡片克隆。
6. 控制器接后备电源，电锁策略与消防联动一致。
7. 验收实测断网放行、权限隔离、补传完整、断电预案。

参考资料

• access-control-fire-linkage
• intercom-access-control-linkage