双屏展厅应用怎么分工：命令走网络、文件走共享目录
展厅里很常见的一种结构：一台操作台（观众伸手能碰到的触摸屏）+ 一块显示屏（观众看的大屏），两台机器各跑一个程序。
它们之间要传两类完全不同的东西：短指令（“切到第 3 页""有新签名了”）和大文件（合成好的几 MB 图片）。把这两类塞进同一个通道，是这类项目最容易走弯的一步。
为什么要分两条路
假设你只用一个网络协议传所有东西，传大图时就得自己做分片、重组、校验、重传——等于重新实现一遍可靠文件传输。而这些能力，操作系统的文件共享早就提供好了。
反过来，如果所有东西都走共享目录（比如靠写文件、对方轮询目录来传指令），实时性又太差，观众点一下要等好几百毫秒才有反应。
所以合理的分工是：
| 数据类型 | 走哪条 | 理由 |
|---|---|---|
| 短指令（切页、状态通知） | 网络协议（UDP / TCP） | 要的是低延迟，数据量极小 |
| 大文件（图片、视频成品） | 局域网共享目录 | 系统原生能力，稳定且零开发成本 |
网络那条只负责传”有新东西了，文件名是 X”这种几十字节的消息，文件本身完全不走它。
谁当服务端，谁当客户端
这个要在设计时定死，不然两边都想主动连对方会很乱。
一个实用的划分是：显示屏当服务端，操作台当客户端。
理由是显示屏那一侧通常是”被动呈现”的角色，它开机就在那儿等着；操作台是”主动发起”的角色，观众操作了才有动作。让常驻的那一端做服务端，逻辑更顺。
当然反过来也能工作，关键是明确写进文档，别让后来接手的人靠猜。
共享目录的几个坑
1. 权限
写入方要有写权限，读取方至少要有读权限。Windows 的共享权限和 NTFS 权限是两套，两边都要对，只改一处经常不生效——这是最常见的”明明设了共享却访问不了”的原因。
2. 路径要用 UNC，不要用映射盘符
映射的网络驱动器（比如 Z:）在用户登录后才挂载，如果程序是以服务方式或开机自启运行的，那时候盘符可能还不存在。直接用 \\机器名\共享名\ 这种 UNC 路径更可靠。
3. 机器名 vs IP
用机器名依赖名称解析，展厅网络里未必稳。用 IP 更直接，但前提是 IP 必须固定——这又回到那条通用建议：展厅设备一律绑固定 IP。
4. 文件写入的原子性
写文件时对方可能正好在读，读到一个写了一半的文件。常见的处理办法是先写成临时文件名，写完再改名——改名是原子操作，对方要么看不到、要么看到的是完整文件。
这一条在实际项目里很容易被忽略，表现为”偶尔有一张图是坏的”。
指令通道的设计
1. UDP 还是 TCP
局域网内的短指令通常 UDP 就够，延迟低。需要确认送达的场景（比如”这条指令必须执行”）用 TCP 更省心。
也可以两者都支持：默认 UDP，遇到问题切 TCP。
2. 指令要能重发
UDP 不保证送达。对于”切到第 3 页”这类幂等的指令，重发几次是安全的（多切几次到同一页没有副作用）。设计指令时尽量做成幂等的，容错会简单很多。
3. 心跳与状态回读
只发不收的话，操作台永远不知道显示屏那边是不是还活着。加一个简单的心跳，操作台就能在界面上提示”显示屏已断开”，而不是让观众对着一块没反应的大屏发呆。
逻辑分层：把不依赖 UI 的部分抽出来
双屏项目的两个程序会有不少共同逻辑——通信协议、文件处理、数据模型。这些应该抽成独立的类库，两端共用。
这样做的好处：
- 两端行为一致，不会出现”操作台按这个格式发、显示屏按那个格式解”
- 这部分不依赖 UI，可以直接写单元测试。展厅项目大多没条件做完整的自动化测试，但把纯逻辑部分测起来成本很低、收益很高
- 改协议时只改一处
常见问题
Q：双屏之间传文件，为什么不直接走网络协议？ A：几 MB 的图片走自定义协议要自己做分片、重组、校验、重传，等于重新实现一遍可靠传输。而两台机器本来就在同一局域网，共享目录是系统原生能力，稳定且零开发成本。网络那条留给短指令。
Q：共享目录设了却访问不了？
A：最常见的是 Windows 的共享权限和 NTFS 权限只改了一处——这两套权限都要对。其次检查是不是用了映射盘符：程序开机自启时盘符可能还没挂载，应该用 \\机器名\共享名\ 这种 UNC 路径。
Q：偶尔会读到损坏的图片文件？ A：写入方写到一半时读取方就开始读了。处理办法是先写临时文件名、写完再改名——改名是原子操作，读取方要么看不到、要么看到的是完整文件。
Q：指令用 UDP 会不会丢？ A：会，UDP 不保证送达。所以指令尽量设计成幂等的（重复执行没有副作用），然后重发几次。需要确认送达的场景改用 TCP，或者加一个应答机制。
这套双端分工的实际落地，可以看某医科大学校友成果展。展厅软件的其他实操见远程运维专题，也可以直接联系我们。