把排队人数、车位余量、天气接上屏？三种数据接法

一、先把责任边界划清

屏只是“显示端”。数字对不对，是业务系统的事；画面稳不稳，是屏和播控的事。签合同和验收时把这两段分开写，出问题时才不会互相推：

• 数据错（叫号乱了、余位数不对）→ 找业务系统那边；
• 显示故障（黑屏、卡住、字太小、亮度刺眼）→ 找屏这边；
• 接口断了不报警 → 是双方都没写清监控责任，属于设计缺陷。

叫号类屏的接口、字号、亮度怎么一起定，可以看 医院叫号屏和导视怎么做。

二、路 A：屏控软件直连数据库

看起来最省事：给屏控系统一个数据库账号，它自己查、自己刷新。

• 改造量：小，有时甚至不用业务系统改代码。
• 成本：低，主要花在数据库授权、网络策略和现场调试上。
• 风险：这是最大的问题。第一，字段名或表结构一改屏就断，而改表结构的人根本不知道有块屏在直连；第二，刷新太频繁会给业务库增加查询压力，高峰期更明显；第三，为了一块屏开放数据库账号，安全审计通常通不过。
• 适合：单机小屏、内网隔离环境、临时验证数据格式。

三、路 B：中间接口或只读视图（多数情况的正确做法）

由业务系统一侧提供一个“只给数据、不动业务”的出口：可以是一个只读接口，也可以是一个数据库视图或中间表。屏控系统按约定周期来取。

• 改造量：中等。真正的工作量在协调——要业务系统厂商配合开接口，这通常是项目里最耗时的一段，不在施工而在流程。
• 要提前约定：字段清单和含义、返回格式、空值怎么处理、刷新周期（常见 5–30 秒一次，取现场要多快和业务系统能承受多少查询）、鉴权方式、超时与重试规则。
• 好处：字段口径由业务方负责，改了会通知；数据库不直接被外部查询；屏侧只认接口，不认库结构。
• 一定要留缓存：接口失败时屏继续显示上一次的数据并标注更新时间，而不是白屏或留一个过期数字不说明。政务、医院这类场景，接口权限和留痕还要按甲方信息部门的规定走。

四、路 C：共享文件轮询（最土但最稳）

业务系统按固定时间导出一份表格或文本（CSV、Excel、JSON 都行），放到约定的共享目录或 FTP；屏控系统定时读取并按模板渲染。

• 改造量：最小。多数老系统本来就有定时导出功能，甚至可以让运维用脚本定时生成。
• 延迟：等于刷新周期，常见 1–5 分钟一次。对排队叫号、余位提示这类场景，要判断“慢一两分钟能不能接受”。
• 优点：不开放任何数据库权限，不要求业务系统开发；改字段只改文件列，双方都好改；出问题看文件就知道是谁的责任。
• 缺点：实时性有限；文件写一半被读取会出现读到旧数据或空行的情况，所以约定“临时文件写完再改名”这种简单规则很重要。

五、三条路对照

车位余量这类还要加一层：传感器和引导屏的校准本身要单独做，接口通了不代表数字准，参考 车位传感器和余位屏怎么校准。

六、对接会上要问清的六件事

1. 数据从哪个系统出，字段由谁定义、谁负责改；
2. 接口或文件由哪一方提供，文档在哪里，有没有测试环境；
3. 刷新周期定多少，业务系统能承受的查询频率是多少；
4. 取数失败时屏显示什么，谁负责发现（有没有告警）；
5. 上线时间：接口联调排在施工之前还是之后，需要停业务系统吗；
6. 显示内容涉及个人信息时的脱敏规则，参考 叫号屏怎么保护患者隐私。

先定系统再谈屏，顺序反过来一定返工，可看 政务大厅叫号屏和导视屏怎么做。

现场清单

• 开工前把字段清单写成一张表：名称、含义、单位、空值处理、变更通知方式
• 明确刷新周期，并在方案里写“数据断供时屏上显示什么”
• 要求业务方提供测试环境和一条模拟数据流，先联调再上真数据
• 接口侧加超时重试和本地缓存，避免断网白屏
• 屏上显示“最后更新时间”，这是几乎不花钱的告警手段
• 涉及个人信息的字段先脱敏再上屏，权限与留痕由甲方信息部门确认
• 验收分两段签字：数据正确性（业务方）与显示稳定性（屏方）

常见问题

问：屏厂说“我们直接连库最快”，要不要同意？ 答：可以让他们连测试库验证格式，正式环境坚持走接口或文件。直连正式库省下的工期，会以未来某天突然不刷新、没人知道为什么的形式还回来。

问：刷新周期是不是越短越好？ 答：不是。周期越短，查询越密，业务系统压力和读取失败率都会上升。按“观众需要多快知道变化”来定，定完写进方案，不要留给现场随手改。

问：数据接上了但数字看着不对，找谁？ 答：先看屏上标注的更新时间。时间在更新说明链路正常，问题在数据口径；时间不动说明取数失败，问题在接口或网络。这一步能让两方不再互相推。

一句话总结：正式项目优先只读接口，老系统走共享文件轮询，直连数据库只做临时验证；把字段口径、刷新周期、断网显示内容和责任人在开工前写成一张表，比选哪块屏更能决定这个项目顺不顺。