让观众把互动内容带走：局域网只读 HTTP + 二维码
观众在展厅里写了签名、拍了合影，想带走。最自然的动作是掏手机拍屏——拍出来是歪的、反光的、糊的。
有个成本很低的做法：**现场机上开一个局域网只读的 HTTP 服务，成品页生成二维码，观众连现场 WiFi 扫一下，直接下载到高清原图。**不用公网、不用服务器、不用注册账号。
为什么不走公网
第一反应可能是传到云上、生成分享链接。但展厅场景下这条路有几个实际障碍：
| 问题 | 说明 |
|---|---|
| 网络不可控 | 展馆的外网时好时坏，甚至根本没有 |
| 隐私顾虑 | 观众的签名、人脸上传到公网，合规上要额外交代 |
| 成本与运维 | 要服务器、要域名、要考虑存储和清理 |
| 故障面变大 | 外网一断，这个功能就没了 |
而局域网方案把这些都绕开了：成品从来没离开过现场，观众和现场机在同一个 WiFi 下完成整个过程。
怎么落地
1. 现场机上跑一个只读的 HTTP 服务
服务只做一件事：把已生成的成品图按 URL 提供出去。只读——不接受上传、不暴露其他目录、不提供目录列表。
展厅现场的 WiFi 通常是开放的，任何多余的写权限都是风险。这个服务的能力越小越好。
2. 成品页生成二维码
二维码的内容就是这张图在局域网里的地址，形如 http://<现场机内网IP>:<端口>/<文件名>。
观众扫码之后手机浏览器直接打开这个地址，图片加载出来，长按保存即可。整个过程不需要装 App、不需要注册。
3. 引导文案要写清”连 WiFi”
这是体验成败的关键一步，也是最容易被忽略的一步。观众不知道要先连 WiFi，扫码之后打不开，就会以为是设备坏了。
屏幕上必须明确写出：先连接 XX WiFi，再扫码下载。WiFi 名称直接写出来，别让观众猜。
几个必须提前定的技术点
1. 现场机的 IP 必须固定
二维码里的地址包含现场机 IP。**如果 IP 是 DHCP 动态获取的，哪天变了，之前生成的二维码全部失效。**必须在路由器上绑定固定 IP，或者直接给现场机设静态地址。
这一条和展厅设备的通用建议是一致的——展厅里所有需要被访问的设备都应该绑固定 IP。
2. 端口不要被占用或被拦
选一个不常用的端口，并确认现场机的防火墙放行。Windows 上新起的服务默认会被防火墙拦，这一步经常忘。
3. 文件命名与清理策略
- 命名：要能保证唯一，避免观众 A 扫码看到观众 B 的图。
- 清理：一天下来会积累大量文件，要有自动清理机制（按时间或按数量），否则磁盘迟早满。展厅是长期运行的，这一条必须在设计时就考虑。
4. 二维码的容错与尺寸
二维码显示在屏幕上，观众隔着一定距离扫。尺寸太小、或者屏幕反光时会扫不上。宁可做大一点，并且避开屏幕反光最强的区域。
顺带解决的一个问题：内容合成
观众要带走的往往不是原始的签名笔迹，而是合成后的纪念图——签名叠在场馆的背景图上，可能还带日期、活动名称。
这个合成动作在现场机上完成，生成的成品既用于本机展示、也用于二维码下载，还可以推送到别的屏上做「签名墙」轮播。一份成品，三个用途，不用为每个用途单独做一套。
跨机推送时，命令和文件建议走不同通道——短命令走网络协议，几 MB 的图片走局域网共享目录，具体做法见双屏展厅应用怎么分工。
这个方案的边界
它不是万能的，以下情况不适用：
- 观众要在离场后再下载：局域网方案只在现场有效，人走了就访问不到。
- 需要长期保存或二次分享：成品留在现场机上，不适合做长期留存。
- 展馆不提供观众 WiFi：整个方案的前提就没了，这一条要在勘场时确认。
如果需求确实包含离场后下载或社交分享，那就得走公网方案，但相应要处理好隐私告知、存储清理和网络可靠性。
常见问题
Q：观众想把签名带走，一定要传到云上吗？ A：不一定。现场机开一个局域网只读 HTTP 服务、成品页出二维码，观众连现场 WiFi 扫码即可下载高清原图。成品从来没离开过现场，不用服务器、不用域名、也没有上传公网的隐私顾虑。
Q：为什么强调”只读”？ A：展厅 WiFi 通常是开放的，任何多余的写权限都是风险。这个服务只需要把已生成的成品图提供出去，不接受上传、不暴露其他目录、不提供目录列表，能力越小越安全。
Q：扫码打不开是什么原因？ A：最常见的是观众没连现场 WiFi——局域网地址在外网访问不到。屏幕上必须明确写出 WiFi 名称和”先连 WiFi 再扫码”。其次要检查现场机 IP 是不是变了、端口有没有被防火墙拦。
Q：文件会不会越积越多？ A：会，所以必须有自动清理机制，按时间或数量定期清。展厅是长期运行的，不设清理策略磁盘迟早满。文件命名也要保证唯一，避免观众扫到别人的图。
这套做法的实际落地，可以看某医科大学校友成果展。互动展项的整体方案见传感器 · 互动感应专题，也可以直接联系我们。