Ubuntu 自助服务终端（Kiosk）搭建：餐厅菜单展示实战指南
Ubuntu 自助服务终端（Kiosk）搭建：餐厅菜单展示实战指南
如果你此刻正在搭建 Ubuntu 自助服务终端，那你大概率不是在做一个科学实验。你是在努力让菜单、点餐页面或顾客交互屏幕在整个繁忙的营业时段保持在线，而不是被别人乱点到桌面、触发更新，或者面对黑屏和经理质问“屏幕怎么又坏了”。
这种需求会改变你构建 Ubuntu 上的 Kiosk 模式 的方式。干净整洁的演示设置远远不够。餐厅里的自助终端必须能经受住触屏的反复敲击、电源波动、浏览器崩溃、会话过期，以及那个总能找出退出全屏的角落手势的员工。好在 Ubuntu 支持 Kiosk 式管理已有很长时间。Ubuntu 社区帮助维基自 2015-08-19 起就记录了 KioskMode，最近更新于 2026-05-02，这清楚地表明，它并不是什么全新小众技巧，而是 Ubuntu 管理领域沿袭已久的模式（Ubuntu KioskMode 文档）。
目录
- 为什么 Ubuntu 自助终端在实际环境中会出故障
- 选择正确的自助终端方案
- 在 Ubuntu 上构建好用的 Chromium 自助终端
- Wayland 与 X11 及 GNOME Kiosk 会话
- 触摸屏、键盘与外设处理
- 在 Ubuntu 自助终端上运行菜单应用
- 加固、远程更新与维护清单
为什么 Ubuntu 自助终端在实际环境中会出故障
在周六晚上9点，没人会在意这台自助终端周二下午在工作台上测试结果有多漂亮。他们只关心菜单屏幕刚才黑了，经历了硬断电后 Chromium 弹出了恢复提示，或者有员工在尝试解冻页面时找到了返回桌面的方法。
这就是 Ubuntu 自助终端常见的失效方式。不是因为 Ubuntu 干不了这份差事，而是因为默认的桌面安装依然表现得像个桌面。它想休眠，它期待干净地关机，它会保留用户状态，并且默认假设触碰屏幕的人只要点击得足够久，就可以进入系统设置。
这种情况我见得最多的就是在餐厅菜单看板和自助点餐屏上。安装过程中看起来一切稳定。然后开始营业，设备被敲打了一整天，屏幕背后的回路毫无征兆地断电，最后有人因为“屏幕卡住了”而插上了键盘。老旧的 LightDM 和 X11 方案让很多这类任务勉强过关，但同时也留下了大量可被突破的后门。较新的基于 Wayland 的方案弥补了其中一些缺陷，同时也带来了不同的运维选择。
导致营业时间损失的常见故障
- 显示器的节能功能仍然有效。 在空闲期间屏幕自动熄灭，在员工和顾客看来就像系统崩溃了。
- 浏览器状态会留到下一人使用。 Cookie、本地存储、强制门户提示或过期会话会渗透入下一次交互。
- 会话仍能回到桌面。 热键、手势、GNOME 叠层或者配置不当的显示管理器会让常规工作站界面暴露出来。
- 更新发生在营业时间内。 软件包提示、浏览器重启和无人值守升级会变成前厅的问题。
- 没有任何程序守护应用。 一旦 Chromium 挂起、关闭，或者在一次异常重启后丢失 GPU 加速，自助终端就会一直死在那儿，直到有人去干涉。
实用原则： 如果一次普通的浏览器崩溃仍需有人到现场处理，说明这台自助终端还达不到生产就绪的标准。
薄弱环节通常不在于“Web 应用与原生应用”之争。关键问题在于，你愿意保留多少桌面技术栈。旧的 Ubuntu Kiosk 改造常用 LightDM、一个自动登录用户和运行于 X11 上的浏览器启动脚本。这依然可行，尤其是在旧硬件或你已经熟悉其各种怪癖的场所。但它也意味着有更多的部件需要监管。现代 Wayland Kiosk 会话和类似家电的方案可以减少那些暴露面，但如果你需要自定义外设、旧的数字标牌工具或偏门的触摸屏驱动，它们可能就没那么宽容了。
餐厅菜单的部署让这种取舍显得很明显。如果机器只需启动、显示在线菜单、从崩溃中恢复且绝不暴露桌面，那么一个极度精简的 Kiosk 会话远比一个伪装的完整 GNOME 桌面更容易相处。如果该场所还需要在同一台机器上使用远程支持工具、打印机测试、员工登录或临时故障排查功能，那么旧的基于桌面的模式就很诱人。而往往，那种便利正是故障的根源。
哪些做法真正靠得住
能安然度过整个周末的 Ubuntu 自助终端都是那些老老实实、平淡无奇的配置。它们使用专用的自助终端用户。它们在操作系统和会话层面关闭了屏幕关闭和挂起。它们通过可控的启动路径启动浏览器，而不是从一个随意的 Shell 配置文件中启动。它们清空或隔离了浏览器状态。它们会在应用退出时自动重启。
Canonical 较新的 Kiosk 指引已朝着原生 Wayland 部署发展，而非过去的“桌面加全屏浏览器”模式，即便你出于兼容性仍选择 X11，这潮流也是个重要的信号（Ubuntu Frame 与现代化 Kiosk 方向）。
真正能在生产环境中支撑下来的，不是那个被装扮得最漂亮的方案，而是那个拥有最少活动部件，同时又能支持你的硬件、浏览器和恢复计划的方案。我在咖啡吧和酒吧的菜单屏幕上采用的标准就是如此，因为迟早这台机器会被错误地重启、被湿手触碰，并被冤枉为一个根本不是它造成的网络问题承担责任。
选择正确的自助终端方案
下午4点时，一个完整的 Ubuntu 桌面 Kiosk 看起来灵活多变；到了晚上9点，当菜单屏幕跳到登录提示、员工为晚餐高峰排起长龙时，灵活性往往就成了麻烦的根源。
Ubuntu 提供了三种目前仍具实用性的 Kiosk 模式。我将其视作三种不同的失效模式。老旧的 X11 和 LightDM 方案容易检查，现场修复也快。较新的 Wayland 和 Frame 方案能去掉很多桌面赘肉，但要求你接受一种更偏电器的操作方式。而单纯的浏览器 Kiosk 居于两者之间，对许多餐厅菜单看板来说，这依然是正确答案。
单店场景的浏览器 Kiosk
当一个流行的餐厅菜单平台（类似 TopFoodApp）已经在浏览器中运行，而屏幕的任务很简单——启动、联网、显示菜单、如果浏览器退出就恢复——那么Chromium 或 Firefox 的 Kiosk 模式最合适。
对于只有一两个显示屏的单家餐厅或酒吧，我仍优先选用这条路。它干净地映射到旧有的 Ubuntu 运维手册上：专用用户、自动登录、受控的会话启动、全屏浏览器、受限的退出路径。如果站点本身就是产品，把它打包成原生应用往往只是徒增工作量，却解决不了那些让你半夜惊醒的问题。
那些问题是运营层面的。浏览器配置会变脏，缓存状态会过期，一次浏览器更新可能毫无征兆地改变自动播放、弹窗或 GPU 行为。这并不表示浏览器 Kiosk 是个坏选择，只意味着你需要一个能快速重置的构建方案。
基于 Snap 的自助终端，简化安装
Canonical 将 Ubuntu Kiosk 部署推向原生 Wayland 工具集是有原因的。旧的桌面技术栈能工作，但它带着一大堆在挂墙菜单屏幕上你根本不需要的东西。Canonical 较旧的 Wayland Kiosk 教程现在已将读者引向更新的方法，这是 Ubuntu Kiosk 方向的一个有用标志（Ubuntu Wayland Kiosk 教程）。
对于希望减少会话级微调的餐厅经营者而言，Ubuntu Frame 加上一个 Kiosk 应用软件包的搭配，会比维护 LightDM、X11 会话文件、浏览器参数和桌面覆盖设置来得更干净。社区中关于这一模式的指南通常遵循相同步骤：安装 Frame，安装 Kiosk 应用，将其与显示服务相连接，让系统直接启动进入应用界面（类似 Ubuntu Frame 风格的设置流程）。
这种干净的模式有个取舍。临时性的修复会不那么方便。假如员工想“就临时用一下桌面”来测试打印机或查看邮件，这种方法会跟他们对着干，而这对于面向公众的菜单屏幕来说通常是件好事。
如果您的应用已经封装在移动端，硬件决策也尚未确定，可以将其与安卓上的专用自助服务终端插件方案对照一下；当你需要比改造后的 Ubuntu 迷你电脑更严格的单应用管控时，安卓硬件可能更匹配。
用于多店连锁的 Ubuntu Core 与 Frame
对于多门店方案，搭配 Ubuntu Frame 的 Ubuntu Core 是我会有意选择，而非逐渐滑入的模式。它表现得更像一台电器，而非一台需要维护的桌面电脑。当你在多家餐厅部署屏幕，且不希望现场人员在打烊后编辑启动文件时，这一点至关重要。
代价是灵活性。你会失去那种老派 Ubuntu 习惯——登录进去，改个脚本，五分钟内又把事情搞定。对柜台上方的一块菜单板来说，这种方式可能显得有点重。但对于一个连锁店面，它通过保持每台设备的一致性，往往能带回足够回报。
Ubuntu 自助终端方案对比
| 方案 | 最适合 | 更新 | 恢复 | 锁定程度 |
|---|---|---|---|---|
| 在 Ubuntu 桌面版上的浏览器 Kiosk | 单家咖啡馆、酒吧、一次性菜单屏幕 | 通过 apt 及浏览器设置管理 | 本地调试容易，但更容易被弄坏 | 低 |
| 基于 Snap 的自助终端 | 希望实现可重复安装的小型连锁 | Snap 管理，以应用为中心 | 应用重启模型更清爽 | 中 |
| Ubuntu Core 与 Frame | 多门店连锁及家电式设备 | 事务性、类镜像工作流 | 设备间一致性最强 | 较高 |
关键问题不在于“Web 还是原生”，而在于你愿意去维护一个桌面会话、一个应用运行时，还是一台锁死的电器。
对于餐厅菜单屏幕，除非有明确理由离开老旧的 X11 和 LightDM 模式，我仍然从浏览器 Kiosk 开始。如果硬件以触控为主、部署需要可重复、或者屏幕会分发到多个场地，那么现代化的 Wayland 路线通常对得起那额外的搭建工作量。
在 Ubuntu 上构建好用的 Chromium 自助终端
在周六晚上9点，没人会在意 Chromium 在安装时曾成功启动过一次。他们只关心这块菜单板在电力闪断后恢复了没有，有没有掉进桌面，也没有把鼠标指针一直留在酒水单上。这就是我用来衡量一台 Ubuntu 自助终端的标准。
对单块餐厅屏幕而言，在 Ubuntu 上的 Chromium 仍是今晚就能让店员用得上的最快捷途径。很多旧教程往往遗漏了会话控制这一部分。--kiosk 只占了一小块拼图。你还需要一个专用用户、每次都能进入正确会话的自动登录、保持关闭状态的闲置设置，以及浏览器崩溃后的重启路径。
创建专用自助终端用户，保持系统精简
为屏幕单独使用一个本地账户。不要复用某位经理的桌面登录，也不可让自助终端共用常规的浏览器配置。共用的配置会收集扩展、已保存的提示、更新提醒和一大堆其它垃圾，末了它们都会跑到正在运营的屏幕上。
只安装自助终端需要的东西：
- Chromium
- unclutter 用于在 X11 下隐藏鼠标光标
- 如果你要搭建经典的 X11 方案而非使用 GNOME Kiosk 会话，就需要 LightDM
我也把浏览器状态放在它自己的配置目录里，这样重置起来很容易。如果站点缓存在营业前坏掉了，你可以直接擦除一个文件夹，而不用去翻整个普通桌面账户。
干净地搭建旧版 X11 方案
如果你正在把较旧的 LightDM 食谱嫁接到较新的 Ubuntu 发行版上，要将 X11 作为一次主动有意的选择，而不是一个遗留的默认项。对于餐厅菜单看板，在已被验证与 LightDM 和 Chromium 配合稳定的硬件上，我仍然使用它。它为人熟悉，容易本地调试，在需要紧急修改启动脚本时也比较宽容。
在 /etc/lightdm/lightdm.conf.d/10-kiosk.conf 处创建一个 LightDM 配置片段，设置：
- autologin-user 指向你的自助终端用户
- user-session 指向你定义的自定义会话名称
然后在 /usr/share/xsessions/ 下面添加一个会话文件，指向你的启动器脚本。
那个启动器脚本应完成四件事：
- 关闭屏幕保护与 DPMS。
- 启动
unclutter。 - 以安全的 Kiosk 参数启动 Chromium。
- 以能让
systemd或会话重启它的方式退出。
适用于菜单屏的常用 Chromium 参数：
--kiosk--noerrdialogs--disable-features=Translate--overscroll-history-navigation=0- 你的固定起始网址
- 如果面板报告的分辨率异常，加上
--window-size=
如果整机其它部分很稳定，就保持系统安装的浏览器软件包不动。把你自定义的行为放到会话文件和包装脚本里。当发行版自带的文件尽量接近原厂状态时，自助终端更容易恢复。
在合适的层面关闭干扰
除非你明确告诉它别这么做，Ubuntu 仍会假设自己运行在一个桌面上。挂起、黑屏、锁屏和空闲动作必须在活动会话能够读到的地方禁用掉。
在一个 LightDM 加自定义 X 会话的构建中，旧的 X11 工具仍然重要。如果会话是 X11，xset s off、xset -dpms 和 xset s noblank 属于包装脚本的一部分。在一台根本不会进入 GNOME 会话的机器上去更改 GNOME 键值，纯属浪费时间，还会让你误以为问题已经解决了。
很多新旧混搭的自助终端改造就走入了这个误区。有人把 Wayland 指南里的 GNOME 设置抄到了 LightDM 的自助终端上，或者把 X11 命令贴进了较新的 GNOME Kiosk 会话中，然后期待得到同样效果。要把修复方法和你启动的会话匹配上。
对于一天之中会更新菜单的情形，浏览器模型能让操作保持简单。员工编辑 Web 应用，而不是去动柜台上的机器。这种模式同样适用于实时更新二维码菜单的场景。
测试故障场景，而不只是启动
一台只能在完全正常的重启下幸存的自助终端，仍然是个半成品。
在你离开现场之前，请测试以下这些情景：
- 冷启动
- 强制结束 Chromium
- 断网后重新连接
- 显示器断电
- 硬断电后重新开机
我还会检查浏览器运行了几个小时后的状况。某些触控覆盖层和廉价 HDMI 转接头在十分钟内表现良好，一旦热量上来就开始出幺蛾子。
如果你需要现场验证参数和启动行为，一段快速的视觉走查会有帮助：
添加看门狗
Chromium 迟早会崩溃。要为这种情况而构建。
对一个单屏餐厅安装来说，一个简单的设置了 Restart=always 的 systemd 服务通常就足够了。一旦包装器退出，或者浏览器挂掉，会话会自动重新开始，无需任何人触碰键盘。比起再把初始搭建时间缩短一分钟，这一个步骤在实际世界里重要得多。
目标就是让它表现得平平无奇。电力恢复了，网络恢复了，Chromium 也恢复了。不等吧台员工认定这台机器有毛病，菜单已经回到屏幕上了。
Wayland 与 X11 及 GNOME Kiosk 会话
围绕 Ubuntu 上的 Kiosk 模式 的混乱，如今大多源于一个事实：老旧的指南默认是 X11 和 LightDM，而新的 Ubuntu 系统会越来越多地把你引向 Wayland 和面向 GNOME 的 Kiosk 会话。两者都能工作，但它们的行为并不相同。
一篇近期关于安全 Ubuntu Kiosk 的文章直接指出了这一错位。较新的指南越来越多地提及 gnome-kiosk-script-wayland 和会话文件的设置，而较旧的方案仍依赖于传统自动登录、Xsessions 和浏览器启动脚本。这让操作者只能去猜测，哪条路对应哪一版 Ubuntu 和硬件的搭配（Wayland 与传统 Kiosk 指引的差距）。
Wayland 下会有哪些变化
在 Wayland 下，合成器握有更多会话控制权。屏幕保护、输入处理和窗口行为都以不同的方式被强制执行。一些旧的 X11 习惯不再能干净地平移过来，尤其是任何依赖 xset、直接 X 会话改造或窗口管理器花招的东西。
这并非坏事。Wayland Kiosk 往往更清爽。但它们也会惩罚那些被生搬硬套过来的 X11 命令。
要检查运行中的系统正在使用什么，可以用 loginctl 查看会话，并确认其类型是 wayland 还是 x11。不要单凭 Ubuntu 版本去假设。
各自的适用场景
| 方面 | X11 会话 | Wayland 会话 |
|---|---|---|
| 浏览器 Kiosk 方案 | 成熟且文档广泛 | 更现代，遗留 hack 更少 |
| 触摸屏顽固问题 | 对老旧硬件有更好的后备 | 在较新 Ubuntu 上为默认佳选 |
| 电源与黑屏控制 | 通常依赖脚本 | 更依赖合成器 |
| 会话锁定 | 更容易临时变通 | 若以正确方式构建则更干净 |
| 跨版本维护 | 旧有指南仍能帮上忙 | 更符合当前发展方向 |
如果你要在 Ubuntu 22.04 或更新的版本上部署，且触摸屏较新，我会默认选择 Wayland。若使用老旧面板、奇怪的 GPU 堆叠，或只有用传统驱动才听话的古董触控控制器，那就守住 X11。
实际决策法则
对于通过 GDM 自动登录进入 Kiosk 会话 的场景，如果希望贴近现代 Ubuntu 桌面技术栈，就采用面向 GNOME 的 Kiosk 路径。对于需要合成器管理的显示设备，Ubuntu Frame 是条更干净的路线。对于那些在 LightDM 加 Openbox 或自定义 X 会话上已正常工作的旧硬件，不要仅仅因为 Wayland 更新就去推倒重来。
错误的方式是在同一台机器上混合两种模式，然后寄望于每个技术栈中有用的部分能互相配合。
如果你在处理 seat 配置或会话包装器，请保持它们极简。一个基本的 seatd 设置应当只为了支撑你所运行的合成器或输入栈而存在。别把陈旧的 X11 变通方案一股脑堆在一个 Wayland Kiosk 上，除非你已证明确实有硬件层面的需求。
触摸屏、键盘与外设处理
一台启动很利索的自助终端，要是触摸层马马虎虎，在现场的感受就会很糟。顾客比管理员更快注意到这一点。如果屏幕的触摸落点偏了那么一点点，如果输入放错了显示器，或者屏幕键盘随机弹出，哪怕浏览器技术上仍在运行，整套方案也会感觉一塌糊涂。
移交前需要调整的项目
- 校准触摸输入。 在 X11 下，
xinput对老旧面板依然管用。在现代技术栈中，libinput和桌面显示设置往往是更干净的途径。 - 把触摸屏映射到正确的显示器。 这在双屏菜单看板和那些内部屏幕仍然存在的改装笔记本上至关重要。
- 禁用用户不需要的东西。 如果店内根本不用屏幕键盘，就把它关掉。如果 USB 键盘只用于服务访问，那就用时再插上并控制好。
避免再次上门的场所检查清单
当我在咖啡馆或酒吧移交自助终端时，会快速过一遍这些现场检查：
- 触摸准确度： 点击屏幕四角和中心。如果竖屏显示器是在安装后才装上去的，要重新检查旋转和映射。
- 光标行为： 确认指针能干净地隐藏，且不会在空闲后重新出现。
- USB 锁定： 只允许自助终端真正需要的设备，比如打印机、扫码器或 NFC 读卡器。其他一切皆应视为潜在风险。
- 唤醒行为： 确保在可变形式硬件上，一次随机的触摸或合盖事件不会让其唤醒至错误状态。
- 输入后备： 如果服务人员需要紧急访问，请记录确切的键盘操作路径，并将其与公开使用流程隔离开。
对于在搭建顾客菜单屏幕的经营者，同样的纪律也适用于内容层面。好的 Kiosk 硬件挽救不了一份杂乱无章的菜单。这份关于如何免费创建带图片的数字菜单 的指南非常有用，因为显示方案和菜单设计需要相互成全。
一台稳定的自助终端会让人感觉不到它的存在。没人评论它，因为根本没人注意这台机器。他们只是乖乖地使用那块屏幕。
在 Ubuntu 自助终端上运行菜单应用
基于浏览器的 Ubuntu 自助终端很适合配合二维码驱动的菜单平台，因为这台机器只需做一件事：打开公开的菜单 URL，保持全屏，并在浏览器退出时恢复回来。这把门店的内容发布流程和显示硬件分离开来。
匹配在于运营，而非单纯技术
对于菜单屏幕，我会将公开的菜单 URL 设置为 Chromium 的起始页，并根据实际面板方向调整窗口尺寸。竖版看板和横版柜台屏需要不同的考量。如果浏览器语言设置应驱动语言选择，那么启动行为应当支持这一设置，而不是迫使店员手动切换。
这种模式的有用之处在于，自助终端不需要 cron 任务、本地内容同步脚本，或每次换个菜品就得手动拷文件。浏览器直接加载最新页面。运营者修改了菜单内容，刷新后自助终端就会体现出来。
来自实际部署的经验
离线行为很关键。如果店内 Wi-Fi 不太可靠，要么依靠浏览器的缓存行为来获得短暂韧性，要么为自助终端提供一个独立的备用联网方式，例如一个普通的 4G/5G 无线网卡（在中国大陆可选用中国移动、中国联通、中国电信的数据卡；台湾地区亦有中华电信等运营商可选）。这往往比再花一小时试图让不稳定的访客 Wi-Fi 看起来稳定要有价值得多。
我也会严格限定交互行为：
- 在可能的情况下禁用意外的浏览器行为，这些行为会把选区或右键操作暴露出来。
- 保持语言切换器可触达，同时不让任何浏览器工具栏或桌面控件出现在屏幕上。
- 在操作系统层面正确设置显示旋转，用于竖挂式菜单看板，而不是仅用浏览器缩放来 hack。
如果你在评估自助点餐屏在技术配置之外是否有商业意义，这篇关于餐厅自助终端成本和投资回报率的分析，会是这份 Linux 搭建指南一个很有用的商业侧补充。
对还没有把菜单体系搭起来的团队，一个免费的菜单制作工具 会降低入门门槛，因为你可以用真实的菜单 URL 而不仅是个占位页面来测试 Kiosk 工作流。
加固、远程更新与维护清单
在自助终端工作中，最糟糕的一个假设是：一旦屏幕启动并进入全屏，任务就完成了。事实并非如此。一台门店里的自助终端就是一台远程电器，而电器需要维护规则。
哪些需要锁死
如果机器不需要多余的桌面项，就把它们删掉。在当前活动会话中禁用注销和切换用户快捷键。如果你仍停留在 Ubuntu 桌面版本，就要让软件包更新保持可控，以免自助终端在营业中途跑偏。如果你管理着多台设备，应通过一个集中流程（如 Ansible 或签名的仓库拉取）来推送变更，而不是在每一台店面机器上手动编辑。
对长时间运行的浏览器会话而言，每晚定时重启仍然是一个实际有效的修补方式。它算不上优雅，但常能防止无人值守屏幕上逐渐累积的缓慢异常。
真正有效的维护节奏
- 每星期： 确认显示屏加载的是正确的 URL，并且能从浏览器重启中恢复正常。
- 每月： 如果浏览器配置越来越臃肿，就清理垃圾；用你惯用的磁盘工具检查存储健康度。
- 每季度： 在计划好的停业窗口内，应用浏览器和平台变更，然后为已知完好的系统镜像做个快照，以便快速替换。
自助终端失效，通常不是因为 Linux 脆弱，而是因为没人对更新窗口、恢复路径和检查清单负起责任。
如果这台机器对营业至关重要，就把它当做一个小型生产系统来对待。这不如打磨启动参数那么光鲜，却是当门店客满时能让屏幕活下来的关键。
一款流行的餐厅菜单应用为餐厅提供了一种快速发布二维码菜单的方式，这些菜单在 Ubuntu 自助终端屏幕上运行得很好，尤其适合那些需要一个稳定的公开 URL、能即时编辑菜单而无需触碰自助终端本身的场景。如果你正在搭建菜单显示屏、收银台屏幕或自助点餐方案，值得在 这款菜单应用 上针对真实的餐厅流程来测试你的浏览器自助终端。