Xibo：把内容更新权交还甲方的开源标牌 CMS

它到底解决什么

展厅交付之后有个长期麻烦，比调试阶段的任何技术问题都更磨人：内容要一直更新。展板换了、活动海报要上、临时公告要发、几个点位的屏各自要显示不同东西。靠人拿 U 盘一台台拷、或者远程连进每台机器换文件，头一个月还能坚持，时间一长必然漏更、错更、忘更。

Xibo 是一套开源的数字标牌系统（官方术语叫 digital signage platform），架构上分两半：CMS（内容管理系统，装在服务器上，用浏览器登录管理）和播放端（装在每一块屏对应的设备上，负责实际播放）。运营人员在 CMS 里传素材、编排布局、配排期规则，播放端联网领取指令，按时间表自动切换内容。官方把这套模式的价值定得很直白：把每天手动换内容的活变成配置一次、之后自动执行，运维不用再守着屏当人肉闹钟。

对展厅项目来说，这填的是一个竞品完全没碰过的空白：站内此前的软件页覆盖的是投影融合、互动引擎、远程运维这些"调试期"工具，Xibo 对应的是"交付之后、内容持续更新"这个长期阶段。

展厅哪道工序会用到它

第一种，入口引导屏。 前台大厅那块屏，平时播欢迎语和参观须知，团体来访时要临时插播定制的欢迎画面，活动期间又要换成活动主题。这类内容变化频繁但播放逻辑简单——不需要感应触发，只需要"到点自动切"，正是 CMS 排期的强项。

第二种，临时活动屏。 甲方经常提前几天甚至当天才定下活动内容，要求某块屏在活动当天临时插播一版专题，活动结束自动切回日常内容。用 CMS 后台配一条排期规则、设好开始结束时间，到点自动生效，不需要现场再派人去接手动切换。

第三种，多点位公告。 楼层导视屏、休息区提示屏、多个展厅分布的告示屏——这些屏内容相似度高、但各自可能要显示局部信息（比如各楼层的电梯故障提示）。一个后台统一看着所有点位的在线状态、统一推送内容变更，比一台台连过去改要现实得多。

怎么获取，该下哪个包

Xibo 分两个部件下载，别搞混。

CMS（服务端）：有两条路。一条是自己下载部署（自建），源码和发布包都在 GitHub 与官方下载页上，CMS 核心遵循 AGPLv3，免费使用；另一条是用官方的 Xibo Cloud Hosting，按订阅付费，官方帮你把 CMS 托管起来，官方宣称能在很短时间内完成部署。这两条路的取舍见下一节。

播放端（装在每块屏对应的设备上）：官方下载页列出的平台是 Windows、Android、Linux、LG webOS、Samsung Tizen、ChromeOS。授权分档是这里最容易踩坑的地方：官方定价页原文写明——Windows 播放端遵循 AGPLv3，免费；Linux 播放端同样走开源免费路线；而 Android、LG webOS、Samsung Tizen 这三类播放端是商用授权，要买永久许可证（或包含在云托管订阅里）。也就是说，同一套 CMS 底下，你给一块跑 Windows 迷你主机的屏装播放端不花钱，给一块商显一体机（跑 Android 或内置 Tizen/webOS 系统）装播放端就要另算一笔授权费。报价时这笔账必须按屏、按平台分开算，不能笼统按"开源免费"报价，也不要反过来把整套都算成收费项。

这里还留了一个口子要提前问清楚：ChromeOS 播放端虽然也在下载页的平台清单里，但官方定价页给出的商用播放端名单只点了 Android、LG webOS、Samsung Tizen 这三个，没提 ChromeOS 归哪一档。项目里要是甲方点名要用 ChromeOS 一体机或 Chromebox，别按开源免费直接估价，也别按商用付费加钱，找官方销售确认这台设备的播放端到底要不要另买许可证，问清楚了再往报价单里填。

装机前还有一层要对齐：官方下载页会把播放端按能配合的 CMS 大版本分成不同批次发布，装机时要对照官方页面选到跟自己那台 CMS 版本代际匹配的那一批，别图省事装了最新播放端却接了一台旧版本 CMS，容易出现连不上或功能对不齐的情况。

最短可用路径

1. 先定服务端在哪。 自建就把 CMS 部署到自己的服务器上；用云托管就在官网开一个实例（官方提供限时免费试用可以先摸一遍再决定）。
2. 给要接的每块屏装对应播放端，按上一节的授权分档选好该下哪个包。
3. 在播放端里填 CMS 的访问地址，播放端联网后会向 CMS 发起连接请求。
4. 回到 CMS 后台的显示设备列表，找到这台新设备，把它"连接并授权"（Connect and Authorise）——没做这一步，播放端联上了也领不到内容。
5. 上传素材、编排一个布局（Layout），把它排进日程表（Schedule），指定播给哪块或哪组屏、什么时间段生效。
6. 保存发布后，播放端会按周期向 CMS 报到，领取最新的排期与素材，之后就是全自动运行。

展厅工程里真正要弄明白的那几件事

架构与服务端要求——这决定要不要额外准备一台服务器

这是售前报价前必须先问清楚的第一件事。自建 CMS 需要什么，官方在定价页"Things to consider"里写得很直接：一台 Web 服务器、一台数据库服务器、常规化的数据备份，网络规模大了还要考虑集群和负载均衡；后续还有服务器维护和 CMS 版本升级这些长期活。官方原话点明这条路"通常总体拥有成本更高"，适合本来就有 IT 团队能扛这些活的甲方。

用云托管则不用准备服务器——官方把 CMS 部署到他们自己的机房，宣称能在很短时间内开通一个实例，数据中心分布在英国、德国、美国、新加坡、澳大利亚几处，按订阅付费。这条路省了自建的运维投入，代价是长期订阅费用和"数据经过第三方托管"这一点（如果甲方对数据存放地有合规要求，要提前确认订阅方案对应的机房所在地是否满足）。

把这两条路翻译成报价单：自建路线报价里要包含服务器（或甲方已有服务器的运维接管）、数据库、备份策略、以及长期的系统维护条款；云托管路线报价里是订阅费加集成实施费，不需要额外报服务器硬件。选错路线，要么甲方多花了不该花的托管订阅，要么集成商漏报了服务器这一项吃了哑巴亏。

开源版、商业版、播放端授权——官方原文分界线

前面下载那节已经拆过一遍，这里把边界说透。官方"开源承诺"页把话说得很清楚："CMS 核心会持续在 GitHub 上以 AGPLv3 开源"、"Windows 和 Linux 播放端会保持开源，零软件授权费"。定价页则明确 Android、LG webOS、Samsung Tizen 播放端是商用永久许可证，按屏收费；云托管订阅里这部分授权费通常已经打包在订阅费里。

翻译成工程判断：如果甲方的屏都是接了 Windows 或 Linux 迷你主机的外置播放盒，播放端这块成本是零，只有服务器和实施费；如果甲方用的是商显一体机、走内置 Android 系统或自带 Tizen/webOS 系统，播放端授权费要单独列进 BOM。这也是选型时值得提前跟甲方沟通的一点——如果预算敏感，优先选支持 Windows/Linux 外置播放盒的显示方案，能省掉这块授权成本。

播放端支持什么平台——影响硬件选型

官方下载页列出的播放端平台是 Windows、Android、Linux、LG webOS、Samsung Tizen、ChromeOS，覆盖了外置播放盒（Windows/Linux 迷你主机、Android 电视盒）和内置播放器的商显一体机（LG webOS、Samsung Tizen 显示器自带的 System-on-Chip 方案）两条路。官方 FAQ 明确说不强制要求专用硬件——现有的显示设备只要系统在支持列表里，就能装播放端复用起来，不必为了上标牌系统换一批新硬件；但官方也建议优先选官方列出的"推荐设备"，兼容性和稳定性更有保障。macOS 与 iOS 官方渠道未见播放端支持，选型时不要假设苹果设备能跑播放端。

网络要求——播放端连不上 CMS 怎么办

播放端需要能连通到 CMS（自建服务器或云托管地址）才能领取新排期、上报状态。官方 FAQ 专门回答过"断网了怎么办"：播放端会把媒体和排期缓存在本地，网络中断时继续按已缓存的内容播放，不会因为掉线就黑屏或停播；恢复联网后再补齐新的排期变更。这意味着播放端不需要一条常年在线的实时连接，间歇性联网、定期签到就够用。

甲方内网隔离场景要按这条来判断：如果播放端能定期访问到 CMS（哪怕网络不稳定、时断时续），排期照常生效，断网期间靠本地缓存顶着；如果播放端从头到尾都连不到 CMS（比如彻底物理隔离、不允许任何出网），那这套系统就没法推送新内容，退化成一块只能播最后一次缓存内容的死循环屏，这时候不该硬装 CMS 体系，用一个纯本地循环播放方案更合适。

和展项播控的分工——最容易选错的一层

这是全篇要讲透的重点。Xibo 管的是"按排期把内容发布出去"，不是"跟中控联动、跟传感器互动"。 两者不是替代关系，选错了会把项目做拧。

Xibo 官方功能列表里确实有几项看起来沾边的东西，容易让人误判：它支持"Interactive Actions"（访客在触屏上点选切换本机布局内的内容，比如菜单板导览）；它还提供一个开放的 JSON API 和外部控制指令（通过消息通道下发"切换布局""叠加播放"这类指令），意味着中控系统理论上可以调用 Xibo 的 API，粗粒度地喊某块屏"切一下画面"。这一点是真实存在的集成能力，做系统集成时可以利用。

但这跟站内讲过的"传感器触发播控""播放触发与互动联动"（见后面衔接部分）完全是两个量级。互动展项要的是：人一靠近，屏幕、灯光、机械几乎同步动起来，中间的信号处理和编排要求实时响应。Xibo 的排期系统和 API 调用不是为这个设计的——它是按分钟、按小时甚至按天为颗粒度的计划任务系统，不是毫秒级的现场演出引擎。真要做人来即播、手势联动这类互动展项，该用的是站内文章提到的播控软件（如 SoftPlayer）配合中控和传感器，Xibo 排不上这个用场。

交付与运维价值——能写进方案和服务条款

把内容更新的权力交还给甲方，这不只是个技术选型，也是能变现的服务点。传统做法是甲方每次要换内容都得联系集成商远程或到场处理，集成商多一笔运维负担，甲方也嫌慢。上了 Xibo 之后，甲方运营团队自己登录 CMS 后台传素材、排日程，集成商只负责前期把架构搭好、把权限和培训做到位——这一步可以单独写进交付文档，也可以包装成一份轻量的"标牌系统巡检与升级"运维服务，而不是把自己变成甲方的免费换图工。

踩坑与排错清单

什么时候别用它

回到 frontmatter 里的边界，展开说：

互动展项、需要实时联动的场景，别用它顶。 Xibo 是排期发布系统，不是现场演出引擎，前面已经拆过这个区别。

甲方既不想自己维护服务器、又不愿意为云托管掏订阅费。 自建有真实的运维投入，云托管是持续成本，两头都不想认的项目，这套体系落不了地。

内网彻底隔离、播放端连不上任何 CMS 的场景。 断网能扛一阵，但完全见不到 CMS 就失去了这套系统的核心价值——内容能远程更新。

屏少、内容常年不变的场景。 一两块屏常年播一个视频，上 CMS 体系是浪费，一个本地循环播放器就够了。

与本站的衔接

• 网络可控播放器的选型基础和免费版常见限制，见 免费网络可控播放器怎么选？。
• 节目排期的时间×空间×内容模型、循环与优先级策略，站内已经拆过一遍，见 节目内容排期与定时分发实战——可以对照着看 Xibo 的排期能力对不对得上这套模型。
• 传感器触发、手势联动这类实时互动展项该怎么做，见 传感器触发播控 与 播放触发与互动联动实战——这两篇讲的正是 Xibo 顶不了的那部分。
• 展厅多媒体播放与多屏同步的整体主题页在 多媒体播放专题；如果要分清"标牌排期"和"中控联动"两条线，展厅中控专题 讲的是另一条线。
• 要把标牌系统写进投标方案，参考 解决方案 里对应展厅类型的运维章节。

脚本是补丁，系统才是底座

脚本适合做的是「一件很小的事」，不是「一套流程」。当你发现每个项目都在重写类似的脚本时，那正是该把它变成产品能力的信号。

企服君中控把这类需求做成系统内的标准能力，脚本回归它该在的位置——临时的、小的、可弃的。见集成商年费方案。

出处

• Xibo 官网首页、CMS 产品页、播放端产品页：https://xibosignage.com/、https://xibosignage.com/cms、https://xibosignage.com/player-app
• 下载页（播放端支持平台清单）：https://xibosignage.com/downloads
• 云托管说明（数据中心分布、部署方式）：https://xibosignage.com/hosting
• 定价页（自建/云托管取舍、播放端授权分档原文、自建所需基础设施清单）：https://xibosignage.com/pricing
• 开源承诺页（CMS 核心与 Windows/Linux 播放端的 AGPLv3 承诺）：https://xibosignage.com/open-source
• EULA（开源组件清单与商用组件许可条款）：https://xibosignage.com/eula
• 功能列表页（含官方 FAQ："What happens to my displays if the internet disconnects?" 断网本地缓存播放原文）：https://xibosignage.com/features
• 帮助与常见问题页：https://xibosignage.com/help
• 用户手册（部署与设备授权流程）：https://xibosignage.com/manual/en/
• GitHub 官方仓库（xibo-cms，AGPL-3.0 许可证元数据）：https://github.com/xibosignage/xibo-cms
• GitHub 组织仓库列表（各组件许可证与维护状态）：https://github.com/xibosignage

本文所述的架构、授权边界与网络行为均来自上述官方材料；具体授权价格、云托管套餐明细与当前支持设备清单会持续更新，报价与选型前请以官网当时页面为准。