LibreOffice Online 重启开发的消息我是在给一台 CentOS 服务器装 LibreOffice 7.6 的时候看到的。一边敲着 rpm 安装命令一边划着 Collabora Online 的更新日志突然意识到这两件事其实早就绑在一条绳上浏览器里跑 LibreOffice 这件事过去几年几乎全靠 Collabora 在撑着现在社区想自己重新把方向盘握回来。对这个圈子稍微有点了解的人都知道TDF 和 Collabora 的关系一直很微妙就像一家开源项目和它的头号商业赞助商合作时亲如兄弟利益上又各怀心事。这篇内容就当是把我最近折腾服务器、查资料、翻源码注释的所得整理出来聊聊 LibreOffice Online 这个重启动作到底意味着什么以及如果你跟我一样是搞运维、做私有化办公部署的接下来该怎么站队、怎么准备。1. 先掰扯清楚LibreOffice Online 到底是什么1.1 它不是“网页版 Office”那么简单很多刚接触的人会把 LibreOffice Online 理解成“把 LibreOffice 搬上网页”这个说法不算错但远远不够。它的核心并不是开发一套新的 Web 应用而是把桌面版那套成熟的文档解析、排版和渲染引擎直接变成后台服务然后通过浏览器界面去操作。换句话说你在浏览器里看到文档是一张“画”这张画是由后台一个真正的 LibreOffice 进程渲染出来的你的每一次按键、每一次拖拽都通过 WebSocket 传到后台由引擎处理后再把最新画面推回浏览器。这个设计思路在 2015 年刚提出来的时候非常超前因为它避免了一个经典难题如果从零写一套云端 Office兼容 docx、xlsx、pptx 的成本高得惊人。而 LibreOffice 用二十年积累下来的兼容层天然就能打开这些格式在线版只需要解决“怎么把引擎跑在服务器上”以及“怎么把画面传到浏览器里”这两件事就够了。1.2 三个核心部件缺一不可LibreOffice Online 的代码库主要由三块拼成。第一块是后台守护进程以前叫 loolwsd后来改名成 coolwsd它的职责是管理每个文档的诞生、销毁、端口分配和会话状态。第二块是前端页面叫 loleaflet它在浏览器里负责绘制工具栏、文档区域和所有交互控件。第三块也是最关键的一块叫 LibreOfficeKit简称 LOK它是桌面版 LibreOffice 对外暴露的一组 C/C API让外部程序能启动一个不显示窗口的 soffice 进程并把渲染结果输出成图片或交互协议。搞过服务端开发的人一眼就能看懂这个架构的风险点每个文档不是一个纯数据文件而是一个活着的有状态进程。一个用户打开文档服务器就要 fork 一个 soffice 实例十个人同时协作同一份文档理论上是在同一个进程里通过会话区分的而不是各开一个。这个特性决定了它的性能瓶颈不在 CPU 有多快而在内存吃不吃得消、进程能不能稳定跑几天不崩。2. 重启开发背后的技术逻辑与方向判断2.1 为什么社区现在才“重启”而不是早就分家LibreOffice Online 这项目其实早年一直是 TDF 和 Collabora 联合推进的code 的大部分也是 Collabora 的员工在写。结果就是大家嘴上都说 LibreOffice Online 是一个社区项目实际维护和发版节奏却高度依赖单个公司的排期。Collabora 的商业产品叫 Collabora Online它的开发版叫 CODE很多功能在 CODE 里先上线过很久才回流到所谓的“社区版本”。问题恰恰出在这里商业公司有自己支持老版本 Office 格式、企业安全审计、订阅功能的推广节奏而社区更关心能不能跟上桌面版 LibreOffice 的迭代速度、能不能把新版修复的 OA 漏洞赶紧补上。两边节奏一旦错开社区就会发现自己在看 Collabora 的脸色行事。这次“重启开发”的信号本质上就是社区想重新掌握主线的 commit 权、规划权和发版权把在线版从“商业产品的附庸”变回“项目的正式成员”。2.2 从代码层面看最优先要解决的是版本滞后我在查资料的时候注意到了一个细节Collabora Online 的稳定版往往基于 LibreOffice 的一个特定旧版本做深度定制比如某段时间 CODE 是锁在 7.3 或者 7.4 的内核上而桌面版已经跑到 7.6 甚至更高。这在商业上可以理解毕竟一个在线服务对稳定性要求极高不可能桌面版一更新就跟着上。但社区一旦重启开发完全可以走激进路线直接以最新稳定版为基线把社区的修改打上去跳过商业版的各种约束。这意味着什么意味着如果你自己编译 LibreOffice Online你很有可能拿到比 CODE 更新的内核修复了更多安全性问题也意味着你要接受比商业版更高的踩坑概率。对那些喜欢自己动手、能搞定编译依赖的运维同事来说这是难得的好消息对只想稳定跑服务的企业来说可能还是要多观察几个版次再上生产。2.3 协同编辑和渲染效率是绕不开的两座山任何一个在线办公产品用户最先感知的体验就两点打开快不快、多人改会不会丢内容。LibreOffice 的同步机制和 Google Docs 那种基于 OT操作变换的协同算法不太一样它更多是依赖每个会话把整块文档状态同步到节点上再做增量合并。实际表现就是三个人同时改同一段文字可能没问题但一个人把整个表格区域拖拽重排另一个人同时往里面填数据冲突和“回滚到旧状态”的情况就会明显增多。重启开发如果只是把文档进程换成新版而不去重构底层的文档同步模型那协同体验依旧不会有质变。我个人判断这次重启的看点很大程度在于他们敢不敢动协同这块老骨架。至于渲染效率目前每个文档进程占用 300MB 到 500MB 内存是很常见的事如果你打算部署一个小规模团队用的在线 Office首先得算清楚内存预算而不是先算 CPU。3. 与 Collabora 的正面竞争是坏事还是好事3.1 看得见的竞争两条子弹路由你选就目前市面上的可用方案来看想跑在线版 LibreOffice要么部署 Collabora Online要么自己搭社区版 LibreOffice Online。过去社区版长期处于“能用但没人管”的状态所以 Collabora 几乎成了唯一答案。重启开发之后局面会变成两个版本并列一个是带着技术支持、订阅服务、商业文档保障的 Collabora Online另一个是跟着社区节奏走、免费但自理生死的 LibreOffice Online。这不是简单的“免费和付费”二选一。从部署形态看两者都依赖 WOPI 协议和对外存储整合技术上能无缝切换的组件不少。从安全修复速度看社区版的发布频率可能更高但补丁的稳定性需要自己验证。从功能完整度看Collabora 在很多高级功能比如表单、邮件合并、移动端优化上投入更多。你选谁本质上是在选“稳定服务”还是“自由主线”。3.2 竞争带来的价格与生态变化软硬件圈有个规律只要一个领域存在真正能打的第二选择第一选择的价格和态度都会好起来。过去 Collabora 社区的定位非常强势企业想用在线编辑能力基本只能买它的订阅。以后社区版要是真的立住了企业就有了谈判的筹码要么你的订阅价格更合理要么我直接自己维护一套社区版。生态层面也很有意思。很多开源项目都在做文档在线预览和编辑比如 Nextcloud 上的 Richdocuments它其实只是 WOPI 客户端真正干活的是配合 Collabora Online 或者未来的 LibreOffice Online。社区版活过来之后Nextcloud 这类项目就不用被绑在单一商业服务上可以同时适配两套后端。这种“接口不变、后端可选”的格局对生态的健康发展帮助很大。3.3 我的个人担忧别把竞争变成分裂我不能光唱好话。开源圈子里一个项目分裂成两个互相竞争的版本往往以悲剧收场因为社区的人力本来就不够分两条线意味着提交分散、Bug 难以集中修、用户不知道该跟谁反馈。LibreOffice 桌面版本身已经很庞大它的在线分支如果也搞出两套互不相让的代码库那长期看维护压力会成倍增加。所以我觉得这个“竞争”与其说是一场博弈不如说是一次“盼了多年的分家重组”。现在最好结果是双方建立一种契约式协作社区版保持独立发版但补丁可以向上游和 Collabora 分支同步Collabora 保持商业定制但把与上游冲突的改动积累到一个可控的补丁集里。用户才能两边受益而不是被迫选边。4. 在 CentOS 上装 LibreOffice 7.6 的实操记录4.1 系统要求与准备前面讲了那么多战略层面的东西落到地面上大家可能更关心“我在服务器上怎么把它跑起来”。我这边整套环境是 CentOS 7.9内存 4GBswap 2GB硬盘只给了 20GB。装 7.6 之前我特意确认了几个基础依赖glibc 版本必须高于 2.17cairo、libXinerama、libXext、dbus-glib 这些图形库一个都不能少即使你是纯 headless 模式LibreOffice 启动时仍会加载图形相关模块。CentOS 自带的 yum 源里 LibreOffice 版本很老通常停在 6.x 或 7.0 附近想装 7.6 就得从官网拉 RPM。两种办法一种是直接下载官网 tar.gz 包解压把所有 RPM 装上另一种是配一个官方仓库地址用 yum install libreoffice。我这次用的是第一种简单直接坏处是后期升级要手动跟进。4.2 完整安装步骤先把官方包下载到 /opt 临时目录cd /opt wget https://download.documentfoundation.org/libreoffice/stable/7.6.0/rpm/x86_64/LibreOffice_7.6.0_Linux_x86-64_rpm.tar.gz tar -xzf LibreOffice_7.6.0_Linux_x86-64_rpm.tar.gz cd LibreOffice_7.6.0_Linux_x86-64_rpm/RPMS看到里面一堆 rpm 文件里面有主包、集成包、中文语言包、帮助包等。如果你想功能完整我建议直接安装全部yum localinstall *.rpm -y如果不想装那么多组件最核心的是那三个主包名字形如 libobasis7.6-core、libobasis7.6-writer 等。不过老实说服务器上缺组件再补装很麻烦不如全装省事。装完验证一下soffice --version正常会输出 LibreOffice 7.6.0 和一长串构建号。如果你刚才装的是包含中文包的版本soffice 已经能识别 zh-CN 区域但默认显示语言还要看系统环境变量。4.3 跑通 headless 转换能力对服务器运维来说装 LibreOffice 往往不是为了做在线编辑而是为了做文档转换服务把 docx 转 pdf、把 xlsx 转 csv。命令行用法很简单soffice --headless --convert-to pdf --outdir /data/converted /data/uploads/report.docx第一次跑会很慢因为要初始化大量动态库和字体缓存后面会快一些。如果报错提示“no suitable windowing system”说明缺图形库用 yum 或 dnf 补装上面提到的那几个软件包。执行转换时最好用独立用户别用 root不然后续用 put 权限或集成到 web 服务时容易踩权限坑。在你准备部署 LibreOffice Online 之前先用这个转 PDF 的命令验一下引擎是否能正常驱动能跑通这个说明 LOK 的底层也就活了后面在线服务的折腾会轻松很多。5. 把 LibreOffice 界面换成中文的三个层级5.1 桌面路径图形界面里点几下如果你在本地装的是带界面的 LibreOffice想换中文最简单。打开一个任意文档菜单栏找到 Tools再进入 Options左侧展开 Language Settings在 Languages 标签页里把 User interface 选项改成“中文简体”或“中文繁体”确认后重启 LibreOffice 即可。注意这里有一个容易忽略的点界面语言和区域格式是两回事你可能想把界面调成中文但数字、日期格式仍然用英文或者中国的习惯需要分别在下拉框里设置。5.2 服务器路径修改配置文件实现凤凰修改服务器上通常没有显示器想通过图形界面设置是不可能的这时要直接改配置。LibreOffice 的用户配置存放在一个独立的配置目录里默认是 ~/.config/libreoffice。启动时可以通过 -env 参数强制指定soffice --headless -env:UserInstallationfile:///root/.config/libreoffice首次运行会在该目录下生成 registrymodifications.xcu 这个 XML 文件里面存着各种设置项。切换语言需要往这个 XML 里写入一条配置item oor:path/org.openoffice.Setup/L10nprop oor:nameooLocale oor:opfusevaluezh-CN/value/prop/item改完保存再启动 soffice 就能认出中文界面。不过服务器上并没有真正界面可看这个配置的主要作用是影响命令行动态库的语言标记比如某些导出错误提示会跟着走意义不大。要真正影响每次文档转换时的字体和区域更可靠的做法是设置系统环境变量export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8把这两行写进 /etc/profile.d/libreoffice-lang.sh然后 source 一下所有新起的 soffice 进程都会认为当前区域是中国大陆排版、日期格式和默认字体选择都会跟着变。5.3 缺少中文字体导致的经典乱象不管界面语言怎么设服务器上一旦缺中文字体导出的 PDF 里中文一定会变成方框或者乱码。判断方法很快fc-list :langzh如果输出几乎没有中文字体就装一套文泉驿或者 Noto CJKyum install -y wqy-zenhei-fonts wqy-microhei-fonts也可以从源里找 noto 的 cjk 包。装完别忘刷新字体缓存fc-cache -f一个隐藏极深的坑是yum 源里那两个字体包只解决了基础显示PDF 导出时的嵌入字体策略如果不正确哪怕系统有字导出的文件在别人机器上依然缺字。稳妥办法是在导出参数里额外指定字体集或在系统上装 fonts-ttf-dejavu 一类的通用包兜底。6. 在线部署与日常维护中的问题排查6.1 端口与 WebSocket 代理配置LibreOffice Online 的 loolwsd/coolwsd 默认监听端口是 9980而且强制要求 HTTPS除非你在配置里开 allow-http。我们做内网测试时图省事开了 http结果浏览器里的 WebSocket 连接死活握手失败。查来查去发现是自己 Nginx 反代没把 /ws 路径解析好。很多人部署时只在反向代理里做了普通 http 的 location 转发忽略 /ws 前端核心的连接逻辑导致的故障现象就是“打开文档能看但一点编辑就断开”。正确思路是确保反代配置里对 /loleaflet、/lool 这些路径做了 WebSocket 协议升级比如在 Nginx 中显式使用 Upgrade 和 Connection 头字段。如果容器化部署记得把 9980 端口别只映射到 127.0.0.1 上否则外部服务连不上。6.2 服务器内存满载与文档进程僵死装了在线版后最常遇到的“压死骆驼的稻草”就是内存。我在一台 8GB 机器上同时打开 12 个文档内存吃掉快一半。更麻烦的是某些文档进程会因为异常输入或超大文档变得僵死既不响应请求也不退出。没有监控基础设施时最简单的保命手段是写一段定时脚本超过 2GB 的 soffice 进程直接 kill然后让 loolwsd 重新拉起会话。如果你是在专业环境里跑建议按“每个活动文档 500MB 基本系统 2GB”的公式规划内存。另外做好文档大小上限限制比如超过 200MB 的文档直接拒绝在线打开宁可提供下载转换也不要让它吃光你的服务器。6.3 协同编辑冲突与文档锁协同编辑是在线版的核心卖点但 LibreOffice Online 的锁机制比 Google Docs 弱不少。实测下来两个人同时编辑不同区域通常没问题但假如两个人同时修改同一批单元格后保存的用户可能会看到“文档被另一用户修改”的提示而不是自动合并。重启开发之后这块被重点优化的可能性很大但眼下你我部署时仍需谨慎。规避方法无非三条一是明确团队内部的小规模并行编辑策略二是配置好自动保存间隔让冲突窗口尽量缩到最小三是在存储端提前用 WOPI 回调做好版本快照。多数时候和企业协同办公系统的对接靠的不是 LibreOffice 本身的协同算法而是周围那层防冲突的壳够不够硬。6.4 快速判断“这是配置问题还是程序 Bug”很多人在论坛上发帖问“LibreOffice Online 为什么连不上”排查时我会先做一次四步隔离。第一确认 soffice --version 能正常输出这一关挂了说明基础安装没成功。第二用浏览器直接访问 loolwsd 的 9980 端口能出来一个最简 HTML 界面才说明服务进程活着。第三查看日志通常日志文件在 /var/log/libreoffice 或 loolwsd 同目录下里面有错误行、端口冲突和命令参数。第四把配置里的 HTTPS 临时关掉、代理全部撤掉在纯局域网环境下再试一次如果纯环境能跑问题就锁定在反代或证书等外层别急着怀疑内核。这个排查逻辑陪我过了很多次线上故障比在一堆配置项里瞎猜高效得多。结尾所以重新拼装一下吧重启开发这件事往小里看只是几条 commit 和一个新闻标题往大里看却是 LibreOffice 在线路线重新洗牌的起点。我个人在实际操作中的体会是不管社区版和 Collabora 最后怎么竞争底层的一切都离不开那台能稳定跑 soffice 的服务器、一套可靠的中文字体还有一份耐心做配置和排查的心态。在线办公没有银弹它就是把桌面版的成熟引擎、网络协议的复杂性和运维的耐心绑在一起慢慢磨。最后再分享一个小技巧如果你想低成本测试这个趋势不用急着拉整个在线版源码先在一台 CentOS 虚拟机里把 LibreOffice 7.6 装好再配合 Nextcloud 的 WOPI 插件跑一个最简单的文档预览流程你会比只读新闻的人更快看清这条路通向哪里。
