市面上的广告机管理软件大部分是纯云端 SaaS 架构设备装个 APP内容从云服务器下发。日常用着没问题但很多用户是在第一次断网时才发现问题——新内容推不下去旧内容播完黑屏远程管理完全失灵。这不是某个厂商做得不好而是纯云端架构的必然结果。本文从架构层面分析原因并给出选型时判断断网不停播的技术方法。一、纯云端架构的依赖链一个典型的云屏 SaaS播放链路是这样的管理端 App/Web ↓ ① HTTPS 云端 API 服务器内容存储、排期计算、设备鉴权 ↓ ② HTTPS / WebSocket 长连接 显示端 APP拉取节目单 → 下载素材 → 解码播放看起来只有三段但每一跳背后的真实依赖是环节实际依赖任何一环断掉的结果管理端→云端DNS、运营商链路、云服务商可用性无法下发任何指令云端本身厂商的服务器、数据库、CDN所有设备同时失控显示端→云端门店宽带、路由器、WiFi该设备失控问题就出在这里这条链路上没有任何一个环节是你可以控制的。门店路由器重启、宽带欠费、光缆被挖断、云服务商故障、厂商跑路——任何一件事发生你的屏幕都指向同一个结局失控。二、为什么播完就黑屏很多人以为断网后设备至少应该继续循环播放之前的内容。要不要继续播取决于显示端 APP 的内容管理策略而纯云端 SaaS 出于成本考虑普遍采用瘦客户端设计素材不做全量本地缓存只缓存当前播放的一个节目排期表存在云端设备每次启动时拉取授权鉴权依赖云端验证这样的设计下断网后会发生什么场景 A断网时正在播节目 N → 播完后拉取不到节目 N1 → 无排期表可用 → 黑屏 / 停在最后一帧 / 回到开机默认画面 场景 B设备断电重启后没网 → 拉取不到排期表和素材 → 直接无法开播瘦客户端不是偷懒是商业考量云端全托管意味着厂商对付费、授权、功能的控制力最强。架构选择背后是商业模式商业模式决定了断网时的表现。这一点选型时看宣传页是看不出来的。三、断网不停播需要什么架构要真正做到网断了屏幕继续播显示端必须是胖客户端——内容、排期、播放逻辑都要在本地闭环显示端本地需具备 ├── 节目全量缓存素材完整落到本地存储 ├── 排期表本地执行定时切换不依赖云端触发 ├── 断网降级策略失联后继续按本地排期播放 └── 授权本地校验不因断网而停止已授权功能满足这四条的设备断网后和联网时的唯一区别是收不到新指令已下发的节目和排期照常执行。餐厅的早午晚菜单切换、政企大厅的办事指南轮播都不受影响。更进一步如果厂商同时支持内网直连、私有部署Docker 部署到自己的服务器、U盘播放、本地文件夹播放等投放方式那么即使公网完全不可用也有本地方案兜底——这类多模式系统断网时的表现和纯云端是两个物种。四、选型时怎么验证不用等到断网不要信宣传页上的支持离线播放几个字用这三个问题实测问题 1投放一个节目后拔掉设备网线让它播完当前节目。合格自动进入下一个节目排期照常不合格黑屏、卡住、回到默认画面问题 2断网状态下重启设备。合格开机自动加载已缓存的节目和排期正常开播不合格卡在加载页提示设备未连接之类问题 3问厂商排期切换是云端触发还是设备本地执行本地执行到点自己切断网也能切云端触发断网时排期失效这是很多产品文档里不会写的关键细节这三个测试十分钟就能做完但能直接筛掉一大批纯瘦客户端架构的产品。五、总结纯云端 SaaS 的断网停播不是 bug是架构的必然。它的商业模式决定了显示端做瘦、控制权留在云端。对于设备能稳定联网、能接受断网即失控的场景这类方案没有问题但对于餐饮、政企、连锁门店这类网络环境不可控的场景选型时应该直接排除。判断标准很简单把上面三个实测问题跑一遍。真金不怕火炼架构有没有本地闭环一试便知。