1. 先搞清楚：CentOS 7上装LibreOffice，到底难在哪
CentOS 7服务器上装LibreOffice这件事，不少人第一反应是：不就是一个 yum install 的事吗？真这么简单就好了。我见过太多人在内网服务器上装完LibreOffice，开开心心写了个转换测试，结果文档一生成，中文全是豆腐块，英文数字正常，标题乱成一片，然后开始怀疑人生。
这篇东西要解决的就是两个问题：第一，CentOS 7上怎么把LibreOffice装好，并且是能用的版本；第二，怎么把中文字体装进系统，让LibreOffice渲染中文文档不再出现乱码和方块。这两个问题往往是绑在一起出现的——服务器上部署LibreOffice，十个里有八个是为了做文档在线预览、格式转换、批量导出PDF这类后端服务，中文是绕不开的刚需。适合谁来参考？后端开发、运维工程师、做Docker镜像打包的同事，以及所有需要在Linux服务器上处理Office文档的小伙伴。
先说点实在的：CentOS 7的生命周期已经步入尾声，软件源迁移到vault归档源后，很多默认仓库里的软件版本就冻结在老版本上。系统自带的那个LibreOffice（如果有的话）通常是5.4甚至更老，解析新版docx、带复杂样式的PPT，效果只能用“凑合”来形容。所以生产环境我一般不推荐直接用系统yum源里的LibreOffice，而是用官方发布的RPM包，装7.x版本。这也是为什么很多教程都强调“去官网下RPM包”而不是直接 yum install libreoffice。
还有一个很多教程没告诉你的事：CentOS 7本身不带任何中文字体，装完LibreOffice，哪怕你转换的是一个纯中文的txt文档，输出PDF照样可能全是方块。原因很简单，LibreOffice本身只是个渲染引擎，它自己不携带字体，所有字符都要靠系统中fontconfig管理的字体来渲染。系统里一个字都没有，那它画出来的自然就是空方框。
所以我把整件事分成三条线来看：装软件、补依赖、配字体。缺了任何一条，都会在后续使用中露馅。
2. 安装前的系统准备与依赖确认
2.1 检查系统版本与已存在的办公套件
动手之前先花两分钟摸清现场。登录服务器，先确认一下系统版本：
cat /etc/redhat-release如果是 CentOS Linux release 7.9.2009，那就对上了。接着看系统里是不是已经装了老版本LibreOffice或者OpenOffice：
rpm -qa | grep -i office which soffice这一步非常关键。我遇到过一台服务器，系统里残留着OpenOffice，新装LibreOffice时rpm包之间产生了菜单项冲突，导致desktop-integration包怎么都装不进去。处理方案其实很简单：老版本办公套件先卸干净再说。如果确定不需要老版本，直接：
rpm -e --nodeps $(rpm -qa | grep -i openoffice)注意，--nodeps 是个双刃剑，能不用就不用。但如果老版本死活卸载不了，而它又不影响业务，那可以保留着，安装LibreOffice时跳过desktop-integration包也行。不过我不建议这么干，后面出问题你会分不清到底是哪个套件在捣乱。
再确认一下架构，x86_64还是aarch64，这决定了你下载哪个架构的RPM包。CentOS 7服务器99%是x86_64，但偶尔也有arm架构的机器，这一步省不得。
2.2 更新软件源与预装依赖
CentOS 7的yum源用默认mirrorlist已经非常慢了，新装系统建议先换到可用的源。这里不做太多展开，只提醒一个重点：不管你用哪个源，epel-release 建议先装上，因为后面排查依赖时有很多辅助工具在默认源里没有：
yum install -y epel-release yum makecacheLibreOffice的RPM安装包对图形库的依赖不少，官方文档里写了需要这些基础库：libXinerama、cups-libs、dbus-libs、glibc、libstdc++、fontconfig、freetype、libXext、libXrender。在CentOS 7上完整装一遍：
yum install -y libXinerama libXinerama-devel cups-libs dbus-libs libXext libXrender libICE libSM libX11 libXau libXdmcp libxcb glibc libstdc++ fontconfig freetype有人会问，我只是做headless转换，也要装这些图形库吗？要。LibreOffice虽然可以无显示环境运行，但它编译时链入了X11的库，缺了这些so文件，启动直接报错，报错信息还特别隐晦——有时候只说“cannot open shared object file”，有时候干脆就卡死不动。所以在最小化安装的CentOS 7上，先把这些依赖补齐是最省心的做法。
还有个容易被忽略的：如果后续要用Java调用LibreOffice（比如通过JODConverter），需要检查一下系统里的JDK版本。LibreOffice 7.6官方支持Java 8以上，CentOS 7默认OpenJDK 1.8可以直接用。不需要Java环境的可以跳过，LibreOffice本身不依赖Java也能做命令行转换。
3. 安装LibreOffice的两种实操路径
3.1 在线安装：yum localinstall走一遍（适合能联网的测试机）
LibreOffice官方发布的Linux版RPM包，下载下来是一个几百MB的压缩包，解压后里面是一大堆RPM文件。网上说的“在线安装”，其实也不是真在线，而是把RPM包下载到服务器本地，再用yum的localinstall去解依赖。
我习惯把安装包放到 /opt/libreoffice_setup 目录下，解压出来：
mkdir -p /opt/libreoffice_setup tar -xvzf LibreOffice_7.6.4_Linux_x86-64_rpm.tar.gz -C /opt/libreoffice_setup解压后你会看到一个 RPMS 目录，里面几十个rpm文件。先不要急着 rpm -Uivh *.rpm，那样装容易顺序错乱导致依赖失败。推荐做法：
cd /opt/libreoffice_setup/LibreOffice_7.6.4_Linux_x86-64_rpm/RPMS yum localinstall -y *.rpmyum localinstall 会自动读取RPM包之间的依赖关系，把缺的库一起从软件源里拉下来装好。实测下来，只要第2章的依赖预先装了，localinstall基本不会报错。如果企业内网没有外部yum源，那就得走下面离线那条路。
安装完成之后，LibreOffice默认装在 /opt/libreoffice7.6 目录下。验证一下：
/opt/libreoffice7.6/program/soffice --version如果能看到 LibreOffice 7.6.4.1 这样的版本号输出，说明主程序已经安装成功。
接下来还有个细节：RPMS目录装完后，官方包里其实还有一个 desktop-integration 目录，里面有让你把LibreOffice集成到GNOME/KDE桌面的菜单包。纯服务器环境不需要这个，我都跳过。装了反而可能因为缺少桌面环境报错。
3.2 离线安装：RPM包手动分发（生产内网更常见）
生产服务器不能上外网，这是常态。离线安装的核心思路：在一台能联网的测试机上把RPM包和依赖库全部下载好，再拷到目标服务器上装。
依赖库可以用 yumdownloader 工具一次性拉下来：
yum install -y yum-utils mkdir -p /opt/libreoffice_deps yumdownloader --resolve --destdir /opt/libreoffice_deps libXinerama cups-libs dbus-libs libXext libXrender freetype fontconfig然后把这个 deps 目录和 LibreOffice 的 RPMS 目录一起打包，拷贝到内网服务器。内网安装时先装依赖：
cd /opt/libreoffice_deps rpm -Uivh *.rpm --nodeps --force生产环境离线装依赖，--nodeps 有时候没法完全避免。但注意，这个操作只在依赖库打包完整的情况下才安全，否则后面LibreOffice装完启动不了，排查起来更麻烦。我的经验是依赖库宁多勿少，把第2章列出的所有库都下载下来，反正加起来也没多大。
依赖装完，再装LibreOffice本体：
cd /opt/libreoffice_setup/LibreOffice_7.6.4_Linux_x86-64_rpm/RPMS rpm -Uivh *.rpm如果提示某个包依赖缺失，用 rpm -ivh 单个安装报错的包，再回到目录里继续装剩下的，这样能精确定位缺哪个库。不建议一上来就 --nodeps，除非你非常确定系统环境已经是干净的。
这个问题我踩过不少次。有一次在内网装到 liblibreofficekit 这个包时卡住，提示需要 liblangtag、libnumbertext 这些库，这些库在CentOS 7默认源里根本没有，最后是从COPR源里找到了RPM包拿进去装的。所以离线安装前最好还是准备一台联网机器试装一遍，确认依赖全了再打包带走。
4. 中文字体部署：乱码解决全过程
4.1 字体从哪来：合法获取与文件准备
LibreOffice装好了，打开文档看到中文全是方块，此时系统里连一个中文字体都没有。中文字体的获取路径有三条，我按推荐程度排一下。
第一条路径：使用开源中文字体，首推思源黑体（Noto Sans CJK SC）和思源宋体（Noto Serif CJK SC）。这类字体没有版权风险，也是目前质量最高的中文字体之一，简体、繁体、日文假名都覆盖，适合企业内网部署。CentOS 7通过epel源可以尝试安装：
yum install -y google-noto-sans-cjk-fonts google-noto-serif-cjk-fonts如果软件源里没有（不同源情况不一样），那就下载Noto字体包手动部署。注意，CentOS 7上包名可能是 google-noto-sans-cjk-fonts，也可能是 noto-sans-cjk-fonts，装之前先 yum search noto 看一眼。
第二条路径：从已有的Windows机器上拷贝字体文件。宋体（simsun.ttc）、微软雅黑（msyh.ttc）这类字体，在公司内部使用实测中很常见。但这里必须提醒一句：Windows字体是有版权的，仅限于你个人使用的机器，如果公司生产环境要商用，建议走第一条路用开源字体，避免后续麻烦。拷贝时记得把 simsun.ttc、msyh.ttc、simhei.ttf 这些常用字体都拿上。
第三条路径：使用文泉驿系列字体。文泉驿正黑、文泉驿微米黑是国产开源字体，CentOS的软件源里有，安装命令：
yum install -y wqy-microhei-fonts wqy-zenhei-fonts这个字体渲染中文没问题，但单个字体文件较大，且字体风格偏印刷体，做常规办公用足够了。我的建议是：能装思源就装思源，装不上的时候文泉驿保底。
4.2 字体安装三步走：拷贝、改权限、重建缓存
不论字体文件从哪里来，安装方式都一样。先建一个专门的目录：
mkdir -p /usr/share/fonts/zh_CN然后把字体文件放进去。ttc、ttf、otf格式都行，LibreOffice通过fontconfig都能识别：
cp simsun.ttc msyh.ttc simhei.ttf /usr/share/fonts/zh_CN/ cp NotoSansCJK-Regular.ttc /usr/share/fonts/zh_CN/接下来改权限。这个细节容易被忽略：如果服务器上LibreOffice是以普通用户身份跑的，字体文件权限不对就读取不了。目录权限755、文件权限644是最稳妥的：
chmod 755 /usr/share/fonts/zh_CN chmod 644 /usr/share/fonts/zh_CN/*然后是最关键的一步：重建字体缓存。Linux系统靠fontconfig管理字体，字体文件放进目录后，必须让fontconfig重新扫描一遍才能被发现：
fc-cache -fv /usr/share/fonts/zh_CN看到“fc-cache: succeeded”这样的输出就说明缓存更新完成了。检查一下字体是否能被识别：
fc-list :lang=zh这个命令会列出所有支持中文的字体，如果列表不为空，那就成功了一大半。再精确验证某个字体：
fc-list | grep -i "simsun\|microsoft yahei\|Noto Sans CJK"看到对应字体路径输出，就说明LibreOffice已经能感知到这些中文字体了。
4.3 按需定制：只装宋体黑体还是全套
字体不是越多越好。有些工程师把Windows下Fonts目录整个拷贝到服务器上，结果LibreOffice启动变慢，字体解析开销变大，转换耗时反而涨了。字体文件越多，fontconfig缓存越大，LibreOffice启动时加载字体列表的时间就越长。
实际项目里分两种情况。场景一：只是把 docx 转成 PDF 供在线预览，这种场景装一个思源黑体就够，中文文档、表格、PPT都能正常渲染，不需要纠结是不是宋体。场景二：业务方对格式有严格要求，比如合同、公文类文档，模板里指定了宋体，那就要把 simsun.ttc 装上，否则LibreOffice会用默认字体替代，输出PDF排版会崩。
推荐组合是：NotoSansCJK + SimSun + Microsoft YaHei。这三款覆盖了办公场景最常见的黑体和宋体，体积也可控，默认字体文件加起来大概一百多MB，完全不影响性能。
有个小技巧，装完字体如果LibreOffice正在运行，记得重启相关进程再测试。字体缓存是系统级的，但LibreOffice在启动时会把字体列表加载到内存里，运行中装上字体并不会自动刷新。
5. 转换验证与常见故障排查实录
5.1 用命令行验证中文转换是否正常
一切装完后，用真实文档做一次全流程验证。写一个简单的中文docx不方便？可以先用LibreOffice自己新建一个：
cd /tmp /opt/libreoffice7.6/program/soffice --headless --convert-to docx --outdir /tmp test.txt用自带的test.txt生成的docx来测试，最多只能验证软件本身能用，中文渲染还得靠真实文档。最直接的方法是准备一份带中文的docx，转成PDF看看效果：
/opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp /tmp/测试文档.docx转换完成后，把生成的PDF下载到本地打开，仔细检查中文显示是否正常、表格边框是否完整、字体是否被替换。这里有个常见误区：只要PDF打开不是方块，很多人就觉得字体OK了。但更隐蔽的问题是——字体被替换了。比如文档指定的是宋体，系统里没宋体，LibreOffice自动用了文泉驿替代，PDF里所有文字都会变“胖”一圈。检查PDF属性栏里的字体列表，确认中文字体名和你预期的完全一致，这才算真正成功。
5.2 事故高发区：权限、残留进程、内存与临时目录
用LibreOffice做服务化部署，常见的坑我一个个说。
第一个是权限问题。很多后端服务用root用户跑，LibreOffice用root启动时可能警告，但能运行。问题是后续如果切换成普通用户跑，第一次执行转换大概率失败，因为/root目录下的LibreOffice配置文件夹（.config/libreoffice）普通用户没有访问权限。解决方法是第一次启动前，先切换成目标用户执行一次：
su - www -c "/opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp /tmp/test.docx"提前生成好目标用户的配置目录，后面再跑就不会碰到“com.sun.star.uno.RuntimeException”这类权限报错。
第二个是soffice残留进程。LibreOffice每次启动都需要几秒钟初始化，如果是通过Java接口反复调用，每次调用都会拉起一个soffice.bin进程，调用完了如果程序没有正常退出，这个进程会一直占着内存。时间一长，服务器上挂着一堆soffice.bin，内存耗尽。
处理方式有两种：要么在调用代码里使用进程池并按需销毁，要么在计划任务里定期清理：
pkill -9 soffice.bin但注意，pkill会让正在执行的转换任务直接中断，在低峰期清理比较稳妥。我用Java做转换服务时，会监控soffice进程数量和内存占用，当连续转换超过500次之后，主动重启一次soffice进程释放内存，实测效果很好。
第三个是内存和临时目录。LibreOffice转换大文档（比如几十MB的PPT）时很吃内存，建议服务器至少预留4GB内存，临时目录 /tmp 也要有足够空间。如果 /tmp 分区比较小，可以指定临时目录：
/opt/libreoffice7.6/program/soffice --headless -env:UserInstallation=file:///opt/libreoffice_work --convert-to pdf --outdir /tmp /tmp/large.pptx通过 -env:UserInstallation 把LibreOffice的工作目录单独隔离出来，既避免污染系统目录，也方便以后排查缓存问题。
5.3 排查速查表
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| 转换报错 java.io.IOException: Connection refused | soffice进程没启动或端口不对 | 检查进程状态，确认LibreOffice能独立启动 |
| 中文显示为方形豆腐块 | 系统无中文字体或字体缓存未更新 | 安装第4章提到的字体，执行 fc-cache -fv |
| 中文显示正常但字体变形 | 指定字体缺失，被自动替换为替代字体 | 用 fc-list 确认对应字体存在，检查PDF字体属性 |
| 安装rpm包时报依赖缺失 | 系统缺少图形库或基础库 | 用yum install补齐后再装 |
| soffice启动后立刻退出 | Java版本不匹配或可执行权限错误 | 检查 /opt/libreoffice7.6/program/ 下的文件权限 |
| 转换速度极慢卡死 | 内存不足、/tmp空间满 | 清理/tmp，释放内存，或指定UserInstallation目录 |
| 部分PPT转换后排版错乱 | LibreOffice版本旧、字体缺失、媒体资源丢失 | 升级到7.6，安装中文字体，检查PPT兼容性 |
Linux下排查LibreOffice问题，最快的办法是直接跑命令行转换，错误信息会直接打到终端。如果你的服务是通过进程调用，看不到终端输出，那就把日志重定向到文件里：
/opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp /tmp/test.docx > /tmp/lo.log 2>&1排查问题时盯着这个日志文件，比四处猜效率高得多。
最后分享一个我自己的习惯：装完LibreOffice和字体之后，我会建一个简单的shell脚本，把“清缓存、杀残留进程、执行转换测试”打成一个命令：
#!/bin/bash pkill -9 soffice.bin fc-cache -f > /dev/null 2>&1 /opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp "$1"以后线上出了中文乱码、转换卡死，先跑一遍这个脚本，八成能恢复。这套组合拳打完，CentOS 7上的LibreOffice基本上就稳了，再配合中文字体的完整部署，各种文档转换、在线预览场景都能顶得住。
