企业官网建设流程全解析

上周有个朋友发来一份 ODT 文件，说在 WPS 里转 PDF 后表格全部错位，问我能不能写个 Python 脚本稳定搞定。这个问题其实特别典型：ODT 转 PDF 在办公自动化里天天遇到，但很多人只会改后缀名、用在线转换网站，文件一多要么格式崩，要么隐私泄露。我自己在几个项目里折腾过各种方案，踩了不少坑，今天把这套实战经验完整捋一遍。内容围绕 Python 调用 LibreOffice 命令行实现文档转换，也会聊到纯 Python 库的局限性、批量并发处理的正确姿势、Web 服务里怎么用才不把进程卡死。适合正在搭建文档处理管线的 Python 开发者，也适合办公自动化刚入门、想少走弯路的朋友。

真正要做的是"渲染"而不是"改名"：ODT 内部是一堆 XML 和资源文件打包成的 ZIP，PDF 则是排版引擎把每个字符、图片、表格按固定坐标绘制出来的结果，两者之间必须有一个软件真正打开文档、计算分页、导出 PDF。LibreOffice 就是干这个的最可靠选择，而且它提供了无需图形界面的命令行模式，非常适合被 Python 脚本调用。

1. ODT 转换 PDF 的本质：为什么看起来简单却问题不断

1.1 改扩展名和真正导出的区别

先回答一个很多人问过的蠢问题：把document.odt直接重命名为document.pdf会怎样？答案是不会怎样，双击打开 PDF 会报错。原因在于 ODT 和 PDF 的文件结构完全不同。ODT 本质是一个 ZIP 压缩包，里面装着content.xml、styles.xml、meta.xml和一堆图片资源；而 PDF 至少包含对象树、内容流、交叉引用表等结构，需要由渲染引擎绘制出来。

可以类比成做菜：ODT 是一份菜谱和一堆食材，PDF 是最终端上桌的成品菜肴。重命名只是给菜谱贴了个"成品"的标签，并没有人真正烹饪。真正的转换，必须由某个软件打开 ODT，解析样式、计算文本流的换行与分页、确定图片位置、处理表格宽度，再调用字体渲染引擎输出页面。LibreOffice、OpenOffice、ONLYOFFICE 这类办公套件内置的就是这个能力。

1.2 市面上能得到的三条路线

从 Python 的角度出发，想要把 ODT 转成 PDF，可选的路线大致三条：

• 调用 LibreOffice/OpenOffice 命令行：最成熟、保真度最高，能处理复杂的页眉页脚、样式、图表。LibreOffice 提供 headless 模式，无界面后台运行，适合服务器。
• 用纯 Python 库解析 ODT 并自己生成 PDF：比如odfpy+reportlab，理论上可行，但实现成本极高，只适用于极简纯文本文档。
• 调用在线转换 API：上传文档然后下载结果，适合不要求隐私、偶尔转换的个人场景，不适合批量自动化，因为网络传输慢、文件大小受限、还有数据泄露风险。

我的选型结论很直接：只要条件是"稳定、私有化、可控"，就选 LibreOffice 命令行。下面所有方案都围绕这条路展开。

1.3 为什么第一个推荐是 LibreOffice

LibreOffice 是自由开源的办公套件，它的 Writer 组件原生支持 ODT 格式，也就是说 ODT 是它自己的文件格式。用自己最熟悉格式的软件去转换，错误率自然最低。它提供soffice命令，可以通过--headless --convert-to pdf直接批量转换，不弹窗、不需要登录、不依赖网络。GitHub 上很多文档转换项目最终都退回到这个方案，道理就在这。

2. 环境准备：Python 环境、LibreOffice 安装和版本兼容性坑

2.1 Windows 系统下安装与配置

Windows 下安装 LibreOffice 很简单，去官网下载最新安装包，安装时一直下一步就行。安装完成后重点注意soffice.exe的路径，默认在：

C:\Program Files\LibreOffice\program\soffice.exe

有些版本也存在于C:\Program Files (x86)\LibreOffice\program\soffice.exe。建议把这个目录加到系统 PATH 环境变量里，否则 Python 每次调用时都要写绝对路径，脚本换一台机器就废了。

添加 PATH 的方式：右键"此电脑" → 属性 → 高级系统设置 → 环境变量 → 在"系统变量"里找到 Path → 编辑 → 新建 → 粘贴安装目录 → 确定。然后在新的命令行窗口里输入：

soffice --version

如果显示版本号，说明配置成功。如果提示找不到命令，多半是环境变量没生效，重开终端，或者直接用绝对路径。

这里有个容易忽略的点：LibreOffice 有 32 位和 64 位两种版本，但 Python 的subprocess调用并不关心位数，只要系统能运行对应程序即可。不过建议和操作系统位数一致，避免某些第三方组件不兼容。

2.2 Linux 系统下的安装与字体坑

Linux 服务器上安装一般用 apt/yum。Ubuntu/Debian 上我通常只安装 Writer 组件，减小体积：

sudo apt update sudo apt install -y libreoffice-writer

如果嫌依赖解析麻烦，也可以直接sudo apt install -y libreoffice，会装全家桶，但磁盘占用多几个 GB。瘦身党可以装libreoffice-core再加libreoffice-writer，不过新手还是建议装完整版，省得缺组件后排查半天。

装完检查soffice是否符合预期：

which soffice

通常输出/usr/bin/soffice。

Linux 上最大的坑是字体。服务器不带图形界面，通常也不装中文字体，导致转换出来的 PDF 中文全是方框或乱码。我踩过不止一次。解决办法是安装中文字体包：

sudo apt install -y fonts-noto-cjk

装完可以用fc-list | grep -i "noto"验证。实际演示时我还专门写过一段代码检查系统中文字体是否存在，后面会给出。

2.3 macOS 上的一行命令

macOS 上用 Homebrew 最方便：

brew install --cask libreoffice

安装后可执行文件路径不是直接soffice，而是：

/Applications/LibreOffice.app/Contents/MacOS/soffice

建议在.zshrc里加一行 alias：

alias soffice="/Applications/LibreOffice.app/Contents/MacOS/soffice"

另外 macOS 会要求首次运行白名单授权，如果在服务器上以launchd方式跑，注意给足够权限。

3. 方案一：subprocess 调用 LibreOffice 命令行的完整解读

3.1 基础命令结构与参数语义

LibreOffice 的命令行转换核心长这样：

soffice --headless --convert-to pdf --outdir /output/path /input/file.odt

四个关键参数逐一解释：

• --headless：无头模式，不启动图形界面。服务器上必须加，否则会因为没有显示器直接报错。
• --convert-to pdf：指定输出格式为 PDF。LibreOffice 内置导入过滤器，会自动根据目标格式调用 Writer 导出。
• --outdir /output/path：指定输出目录。值得注意的是，如果不加--outdir，生成的 PDF 会放在输入文件所在目录并覆盖？实际测试并不会覆盖原 ODT，只是在旁边生成同名 PDF。但为了保险，我始终显式指定--outdir。
• /input/file.odt：输入文件完整路径。路径中不能有不符合编码的字符，否则转换会静默失败。

还可以更精细地指定 PDF 过滤器参数，例如：

soffice --headless --convert-to 'pdf:writer_pdf_Export:{"SelectPdfVersion":{"type":"long","value":17}}' test.odt

这段的意思是使用writer_pdf_Export过滤器，并设置 PDF 版本为 1.7（值为 17 表示 PDF/A-1a？需要注意，不同版本枚举不同）。日常转换不需要这种级别，但当你需要控制 PDF/A 属性、压缩质量、字体嵌入策略时，就需要研究过滤器选项了。一般默认参数已经够用。

3.2 Python 调用代码示例：正确处理路径、输出和退出码

Python 里用subprocess调用时，最忌讳用shell=True拼字符串，因为路径里的空格、中文、引号会让命令直接卡壳。正确做法是把命令参数写成列表，由subprocess自行处理转义：

import subprocess import os import sys def odt_to_pdf(input_path: str, output_dir: str) -> str: input_path = os.path.abspath(input_path) output_dir = os.path.abspath(output_dir) os.makedirs(output_dir, exist_ok=True) cmd = [ 'soffice', '--headless', '--convert-to', 'pdf', '--outdir', output_dir, input_path ] result = subprocess.run(cmd, capture_output=True, text=True, timeout=120) if result.returncode != 0: raise RuntimeError(f"转换失败: {result.returncode}\n{result.stderr}") base = os.path.splitext(os.path.basename(input_path))[0] pdf_path = os.path.join(output_dir, base + '.pdf') if not os.path.isfile(pdf_path): raise FileNotFoundError(f"PDF 文件未生成: {pdf_path}") return pdf_path

几个细节说明：

capture_output=True用于捕获 LibreOffice 的 stdout 和 stderr，方便排查问题。text=True把输出解码为字符串，否则是 bytes。timeout=120防止转换几十页的大文档时进程挂死。如果转换超时，subprocess.run会抛出TimeoutExpired，外层捕获后应该杀掉残留 soffice 进程，这点在并发场景尤为重要。

returncode非零时抛出异常是常规操作。但你一定会遇到"returncode 为零但 PDF 没生成"的情况，比如输入文件损坏、字体缺失时 LibreOffice 可能只输出一条警告，仍然返回 0。所以生成后检查 PDF 文件是否存在非常有必要。

3.3 同名文件覆盖与特殊字符问题

LibreOffice 在输出目录下生成与输入 ODT 同名的 PDF。如果目标目录已经存在同名 PDF，新转换会直接覆盖旧文件，不会有任何确认提示。这个行为在批量重复转换时反而省事，但如果你希望保留历史版本，要自己在脚本里处理冲突，比如按时间戳重命名。

文件名里如果带有&、(,),[,],#等特殊字符，subprocess 列表形式不会有问题，因为没经过 shell 解析。但如果路径里包含非 UTF-8 编码的字符（比如从某个旧 Windows 系统拷过来的 GBK 文件名），Python 侧就可能先报编码错误，这通常不是 LibreOffice 的问题，而是操作系统文件名编码不统一。生产环境中最好在入库时就把文件名统一成 ASCII 或规范 UTF-8。

3.4 高频典型问题：用户配置文件锁导致的间歇性失败

这个坑几乎每个用 LibreOffice 做并发的团队都会遇到。LibreOffice 首次启动会创建一个用户配置文件目录（Windows 在%APPDATA%\LibreOffice\4\user，Linux 在~/.config/libreoffice/4/user）。当你连续调用好几个soffice进程时，它们会争抢这个配置文件，导致报错信息类似：

Error: source file could not be loaded

或者：

The lock file ... already exists, another LibreOffice process is using it

实际上文件本身没问题，纯粹是并发冲突。解决办法是在每次调用时给 LibreOffice 一个独立的临时配置目录：

soffice -env:UserInstallation=file:///tmp/lo_profile_123 --headless --convert-to pdf ...

这样每个进程用独立的 profile，互不干扰。Python 里可以用进程 ID 或随机字符串拼一个唯一路径：

import tempfile profile_dir = tempfile.mkdtemp(prefix="lo_profile_") cmd = [ 'soffice', f'-env:UserInstallation=file://{profile_dir}', '--headless', '--convert-to', 'pdf', '--outdir', output_dir, input_path ]

用完最好把临时目录回收。后面讲并发时还会专门说。

4. 方案二：纯 Python 库方案为什么不可靠——从一个 content.xml 实验讲起

4.1 ODT 内部结构长什么样

为了说清楚纯 Python 方案的局限，我直接解压一个 ODT 文件看看内部结构：

unzip -l sample.odt

典型输出包含：

mimetype content.xml styles.xml meta.xml settings.xml Pictures/1.png manifest.rdf META-INF/manifest.xml

其中content.xml是正文和大部分内容所在，styles.xml保存样式定义，Pictures/是嵌入的图片。我们可以用 Python 的zipfile读取content.xml：

import zipfile from lxml import etree with zipfile.ZipFile('sample.odt') as z: with z.open('content.xml') as f: root = etree.fromstring(f.read()) text_parts = root.findall('.//{urn:oasis:names:tc:opendocument:xmlns:text}1.0/p')

如果文档只有几段普通文字，你会得到清晰的<text:p>列表。这给了很多新手一种错觉：把<text:p>里的文本提取出来，用reportlab一行行画到 PDF 不就行了？

4.2 解析 XML 自己画 PDF 的五个致命伤

真正动手后会发现，任何非平凡文档都会让这个方案崩盘：

• 样式继承：ODT 的文本样式通过<text:span text:style-name="T1">引用样式表中定义的字体、字号、颜色、缩进，而样式表又有段落样式、字符样式、表格样式、页面样式四层。要完整复现，等于重写一个排版引擎。
• 字体度量：PDF 绘制文本必须知道每个字符的宽度，才能计算自动换行和对齐。你需要读取系统字体，计算每个字形宽度，并处理中英文混排时的基线对齐。
• 分页计算：ODT 文档流是动态分页的，段落前后的分页符、表格行跨页、页眉页脚跟随页面样式变化。纯规则引擎很难处理 "keep-next" 这类 Word 处理习惯的段落控制属性。
• 图片位置：正文中的浮动图片、锚定段落、环绕模式，全都需要模拟 Writer 的排版逻辑。
• 表格宽度：ODT 表格列宽可以使用绝对单位、相对百分比、甚至自适应内容。真实世界里的表格几乎都有复杂跨行、跨列、合并单元格，纯 XML 遍历处理会写到你怀疑人生。

结论很明确：除非文档是你自己程序生成的、结构极度受控的纯文本 ODT，否则不要用纯 Python 库转 PDF。这不是 Python 不行，而是 Office 排版引擎本身就是巨大的工程。

4.3 什么场景下纯库方案反而合适

当然，纯库方案并非一无是处。如果你处理的文档是程序自动生成的，比如导出订单、发票、通知函，正文只有标题、段落、一个简单表格，且你已经完全了解 ODT 的结构，那么用odfpy读取内容，再用reportlab生成 PDF，响应速度会更快，也不会依赖服务器上安装 LibreOffice。

我的经验是：凡是"一次性转换用户上传的任意 ODT 文件"都不要碰纯库方案；凡是你自己模板生成的 ODT，数量大、格式固定，纯库也许是爱。但现实里，为了一个纯文本模块去维护两套渲染逻辑，后期成本很高。我最终还是在项目中统一回退到 LibreOffice。

5. 方案三：Windows 没有 LibreOffice 时的曲线救国——ODT 转 DOCX 再转 PDF

5.1 用 win32com 调 Word 直接打开 ODT 的局限性

有些公司只给开发机装了 Microsoft Office，不允许再装 LibreOffice。此时很多同事会想着用pywin32调 Word 的 COM 接口处理转换：

import win32com.client import os def convert_odt_to_pdf_with_word(input_path, output_path): word = win32com.client.Dispatch('Word.Application') word.Visible = False doc = word.Documents.Open(input_path) doc.SaveAs2(output_path, FileFormat=17) # 17 表示 wdFormatPDF doc.Close() word.Quit()

这个方案确实能跑通，但我要说实话：Word 打开 ODT 的兼容性并不好。普通的文本、图片问题不大，可一旦遇到 LibreOffice 特有的样式属性、页面设置、表格边框，Word 渲染结果经常和原文件有差异。更麻烦的是 COM 调用要求机器上有完整的 Office 许可、不允许无头运行，服务器上还会弹出奇怪的交互对话框。若非不得已，不推荐。

5.2 桥接五次不如原生一次：为什么还是建议装 LibreOffice

也有人推出一个"桥接"思路：先用 LibreOffice——等等，既然你都装了 LibreOffice，为什么不直接转 PDF？所以这个思路本质上只在一种情况下成立：你手头既有 Word 又要保留可编辑的 DOCX，需要先转换格式，再交给 Word 做二次处理。但中间转两次格式必然会损失部分细节，浪费的时间和空间也不值得。

我在实际项目里的判断标准很简单：如果服务器允许安装开源软件，优先装 LibreOffice，一步到位；只有当你确定客户环境绝对不允许安装任何额外办公套件、且所有 ODT 文档都是简单格式时，才考虑win32com调 Word。前者稳定可控，后者看人品。

5.3 其他跨平台替代工具：ONLYOFFICE 和 Calligra 值得一提

除了 LibreOffice，ONLYOFFICE Desktop Editors 也支持 ODT 转 PDF，而且它的排版引擎在网页协作场景表现不错。Calligra 是 KDE 社区的办公套件，但成熟度相对一般。服务器自动化领域，LibreOffice 依然是命令接口最完整、文档最多、坑最少的选择。OpenOffice 大家也常用，但它的无头模式 API 更老，新版本不开源支持下更新缓慢。除非公司强依赖 OpenOffice 的 UNO 扩展，否则没必要绕远。

6. 实战：包含图片、表格、页眉页脚的复杂 ODT 转换与异常排查

6.1 准备一个带"料"的测试文档并跑通

为了验证方案的可靠性，我特意用 LibreOffice Writer 创建了一个测试文档test_complex.odt，里面包含：一个三行两列的表格（其中一格跨两列）、一张嵌入图片、打印样式的页眉和页脚、标题下面的一个无序列表。然后在虚拟环境里执行：

python -c "from converter import odt_to_pdf; print(odt_to_pdf('test_complex.odt', 'out/'))"

输出：

/abs/path/out/test_complex.pdf

PDF 打开后页眉页脚完整，图片居中，表格边框无溢出。这个结果说明--convert-to pdf默认导出已经足够处理大部分办公文档。真正复杂的部分往往不是转换本身，而是异常处理。

6.2 生产级函数：超时、临时 Profile、错误号一个都不能少

我整理了一份在多个项目里用过的生产级函数。它比上面的基础版多了四件事：独立临时配置目录、超时后清理进程、返回码非零时打印完整 stderr、生成文件后校验大小非零。

import os import shutil import subprocess import tempfile def odt_to_pdf_pro(input_path: str, output_dir: str, timeout: int = 180) -> str: input_path = os.path.abspath(input_path) output_dir = os.path.abspath(output_dir) os.makedirs(output_dir, exist_ok=True) profile_dir = tempfile.mkdtemp(prefix="lo_profile_") try: cmd = [ 'soffice', f'-env:UserInstallation=file://{profile_dir}', '--headless', '--norestore', '--convert-to', 'pdf', '--outdir', output_dir, input_path ] proc = subprocess.run( cmd, capture_output=True, text=True, timeout=timeout ) except subprocess.TimeoutExpired as e: # 超时后尝试清理残余进程 subprocess.run(['pkill', '-f', profile_dir], capture_output=True) raise RuntimeError(f'转换超时: {input_path}') from e except FileNotFoundError as e: raise RuntimeError('找不到 soffice，是否安装 LibreOffice 并配置 PATH?') from e finally: shutil.rmtree(profile_dir, ignore_errors=True) if proc.returncode != 0: raise RuntimeError( f'LibreOffice 返回码 {proc.returncode}: {proc.stderr}' ) base = os.path.splitext(os.path.basename(input_path))[0] pdf_path = os.path.join(output_dir, base + '.pdf') if not os.path.isfile(pdf_path) or os.path.getsize(pdf_path) == 0: raise RuntimeError(f'PDF 未生成或大小为 0: {pdf_path}') return pdf_path

几个小细节：--norestore防止 LibreOffice 恢复上次未保存的文档弹窗；pkill -f profile_dir用于杀残留进程；最后检查文件大小非零，很多静默失败能在这里被拦截。

6.3 字体缺失导致整页方块的真实案例

有次我在一台干净的 Debian 服务器上跑批量转换，所有中文文本转出来都是"□□□"。逐个排查后，发现服务器上没有任何中文字体。fc-list输出里只有几个 DejaVu 字体，而 DejaVu 不含中文字形。装好fonts-noto-cjk后重新转换，中文恢复正常。

这类问题最坑的地方在于：LibreOffice 不会因为缺字体而报错，它只是找一个能用的字体替代，替代不了就画方框。所以转换后的 PDF 必须做可视化抽查，或至少抽样验证文本内容长度。如果必须自动化检查，可以用pdftotext抽文本：

pdftotext out.pdf - | wc -l

对比源文档的文本量，能发现约八成缺字问题。

7. 批量与并发转换：把脚本从"能用"升级到"抗打"

7.1 批量转换的基本框架：glob + 失败清单

第一步先把"单个转换"扩展成"扫目录全部转换"，同时保留失败清单，不要因为一个坏文件中断整个任务：

from pathlib import Path def batch_convert(input_dir: str, output_dir: str): input_dir = Path(input_dir) output_dir = Path(output_dir) errors = [] for odt_path in input_dir.glob('*.odt'): try: pdf_path = odt_to_pdf_pro(str(odt_path), str(output_dir)) print(f'OK: {odt_path.name} -> {Path(pdf_path).name}') except Exception as e: errors.append((odt_path.name, str(e))) print(f'FAIL: {odt_path.name}: {e}') print(f'完成，成功 {len(list(input_dir.glob("*.odt"))) - len(errors)}，失败 {len(errors)} 个') return errors

如果要遍历子目录，把glob('*.odt')改成rglob('*.odt')。

7.2 concurrent.futures 做并发时必踩的连环坑

很多人写完串行版本，嫌慢，就上了ThreadPoolExecutor。结果发现要么崩溃，要么报 profile 锁错误。核心原因前面提过：LibreOffice 的默认用户配置目录只有一个，多个进程同时写会冲突。解决方案有三个层级：

方案 A：完全不并发，串行跑。文件不多时最简单，不会出问题。 方案 B：限制并发数为 1，本质还是串行，但用线程池统一管理超时与异常。 方案 C：真正的并发：每个子进程都指定独立的-env:UserInstallation临时目录，让每个进程拥有独立 profile。经过测试，并发数控制在 2~4 时，CPU 和内存收益最现实，数量再多容易内存爆炸。

代码示例：

from concurrent.futures import ThreadPoolExecutor, as_completed def convert_one(item): return odt_to_pdf_pro(item, output_dir) with ThreadPoolExecutor(max_workers=4) as executor: futures = {executor.submit(convert_one, str(p)): p for p in input_dir.glob('*.odt')} for future in as_completed(futures): try: pdf = future.result() print('成功:', Path(pdf).name) except Exception as e: print('失败:', futures[future].name, e)

注意：真正的瓶颈通常在内存。每个 soffice 进程大约占用 200~400MB 内存，4 并发就是 1.6GB，服务器只有 2GB 内存时建议 max_workers=2。

7.3 在 Web 服务里避免同步阻塞和后端超时

如果只是写脚本，subprocess.run阻塞没什么问题。但放到 FastAPI 或 Flask 接口里，直接同步调用会让请求线程干等一个 180 秒的转换。正确姿势是：使用线程池把转换任务放到后台执行，并限制并发数量。最简单的示例：

from fastapi import FastAPI, File, UploadFile from concurrent.futures import ThreadPoolExecutor app = FastAPI() pool = ThreadPoolExecutor(max_workers=2) @app.post('/convert/odt-to-pdf') async def convert_odt(file: UploadFile): content = await file.read() # 保存临时文件，调用 pool.submit(odt_to_pdf_pro, ...) # 返回一个 task_id，前端轮询任务状态

真正的生产项目里，我一般不会直接在 Web 进程内跑 LibreOffice，而是把任务丢给 Celery/Redis 队列，由独立 worker 进程去转换，避免 Web 服务器被打垮。如果业务量不大，用线程池加信号量也够用，关键是千万不要用os.system同步调用，否则用户请求线程全卡在等待上。

7.4 日志、重试和统计的工程化套路

工程化脚本还要加日志。核心信息包括：输入文件路径、输出路径、耗时、返回码、stderr 前 500 字符。出现失败时自动重试一次，等待 2 秒，如果仍然失败记入错误清单。

import logging, time logger = logging.getLogger('odt_converter') def convert_with_retry(path, output_dir, retries=2): for i in range(retries): try: start = time.time() pdf = odt_to_pdf_pro(path, output_dir) logger.info('转成功 %s -> %s 耗时 %.2fs', path, pdf, time.time()-start) return pdf except Exception as e: logger.warning('第 %d 次尝试失败 %s: %s', i+1, path, e) time.sleep(2) raise RuntimeError(f'重试后仍失败: {path}')

日志文件名建议按天滚动，不然生产环境日志会巨大。

8. 错误速查表与我的最后几点私货

8.1 高频错误速查对照表

把几年里遇到的典型错误整理成了表格，方便直接查：

这个表不是万能药，但覆盖了 90% 的日常报错。

8.2 我最后想说的几句实在话

搞了几年文档转换，最有价值的教训就是：不要一开始就追求并发和花哨的库，先把最小的串行链路跑通，再不断加防护。LibreOffice 是这里面最普通却最可靠的工具，它没有 Python 生态那种亮眼包装，但一个soffice命令稳定得可怕。

如果你在处理 ODT 转换时遇到格式错乱，先别急着改代码，打开 LibreOffice 人工转一次。如果人工也一样乱，那问题就在源文档本身，不在脚本。如果人工正常而脚本生成的 PDF 乱，再检查字体和profile 锁也不迟。

另外，转换速度真的和机器性能关系极大。小文档 1 秒内出结果，带几十张高清图的文档可能要 10 秒。批量任务上不要盲目设 120 秒超时，可以按文档大小乘以 5 再加 20 秒来动态计算。我的项目中一般做成可配置参数，默认 180 秒。

最后分享一个小技巧：如果你需要转换的 ODT 是从网上银行、政府系统导出的，里面常带数字签名和只读保护。LibreOffice 默认模式会提示输入密码或跳过受保护区域。这时在命令里加一个--writer参数指定文档类型，可以绕开部分保护弹窗。具体写法是soffice --headless --writer --convert-to pdf --outdir ...。遇到导入时弹密码框的文档，不妨试试这个组合，能免去不少人工介入。