本文写的是我们实际交付过的项目，技术细节未作修改；客户主体按行业与规模做了脱敏处理。
某医科大学校友成果展：双屏展厅应用与电子签名墙
这是一所医科大学的校友成果展项目，核心是一套双屏展厅应用，外加一个电子签名互动环节。
双屏怎么分工
现场是两块屏，各跑一个程序：
- 操作台（
XiaoyouConsole.exe）：观众伸手能碰到的那块触摸屏，负责交互和电子签名的整个流程，它是 UDP 客户端。 - 显示屏（
XiaoyouDisplay.exe）：观众看的那块大屏，负责展览内容和签名墙轮播，它是 UDP 服务端。
两端之间的命令走 UDP，但签名成品走局域网共享文件夹。
这个「命令和文件分两条路走」的设计是有讲究的。签名合成图是几 MB 的 PNG，如果塞进 UDP 报文里传，要自己做分片、重组、校验，等于重新实现一遍可靠传输。而现场两台机器本来就在同一个局域网，共享目录是系统层面就有的能力，稳定且零开发成本。UDP 那条路只负责传「有新签名了，文件名是 X」这种几十字节的短消息。
电子签名的完整链路
观众在操作台上手写签名之后，会依次发生这些事：
- 签名笔迹与学校的背景图合成为一张纪念图；
- 成品存本机一份；
- 同时经局域网共享目录推送到显示屏那台机器；
- 显示屏把它加进**「签名墙」轮播**，观众能立刻在大屏上看到自己刚写的字；
- 操作台的成品页生成一个二维码。
第 5 步是这个项目里体验上最讨巧的一环。观众想把自己的签名图带走，最自然的动作是掏手机拍屏——但拍出来是歪的、反光的、糊的。
所以操作台内置了一个局域网只读 HTTP 服务：观众用手机连上现场同一个 WiFi，扫成品页上的二维码，直接下载到那张高清原图。
选择「只读」是刻意的：这个服务只对外提供已生成的成品图，不接受上传、不暴露其他目录。展厅现场的 WiFi 通常是开放的，任何多余的写权限都是风险。
技术栈与一个踩过的坑
工程是 WPF 的桌面应用，运行时是 .NET Framework 4.8.x，编译目标重定向到 v4.7.2。核心逻辑抽在一个不依赖 WPF 的纯逻辑类库（Sign.Core）里，配了 xUnit 单元测试——签名合成、文件推送这类逻辑不该被 UI 绑死，抽出来才能测。
这个项目里最值得单独写一笔的踩坑是：程序集名不能用中文。
工程目录本身是中文命名的（「成果展校友聚力操作台」「成果展校友聚力显示屏」），一开始程序集名也顺手跟着用了中文。结果在 Win11 上，WPF 的渲染线程会崩溃。
最后的处理是：目录名保持中文不影响，但程序集名必须是 ASCII——XiaoyouConsole、XiaoyouDisplay、Sign.Core。
相关的还有一条：XAML 里如果要引用中文文件名的图片，普通的相对路径引用会出问题，得写成：
pack://siteoforigin:,,,/Assets/xxx.png
这两条都是那种「不撞上永远想不到、撞上了排查半天」的坑。展厅项目的资源文件经常是甲方直接给的中文命名素材，很容易踩到。
这个项目的可复用经验
大文件走文件系统，命令走网络。 不要什么都塞进一个通道。局域网共享目录在展厅这种固定环境里非常好用，比自己造轮子可靠。
给观众一个把内容带走的方式。 签名、合影这类互动，如果观众只能看不能带走，参与感会打折。二维码 + 局域网 HTTP 是成本最低的做法，不需要公网、不需要服务器、不需要注册。
Windows 桌面程序尽早把程序集名统一成 ASCII。 这条几乎不花时间，但能省掉一次莫名其妙的渲染崩溃排查。