电子书转PDF完整指南：从格式原理到工具选型与排版校验

先说一个很多人的迷思：把.epub后缀改成.pdf，文件是能打开，但排版彻底废了——段落在屏幕边缘直接截断，图片挤在一起，目录全部变成超链接代码，连中文字体都变成豆腐块。这是我在处理“电子书转PDF”这个需求时遇到最多的入门错误，也恰恰说明了想做好这一件事，不能只靠“会用某个转换器”，得先搞明白 EPUB、MOBI 跟 PDF 在底层到底有什么不同。

这篇内容会围绕电子书转 PDF 的完整链路来讲：先讲格式差异决定的转换原理，再讲工具选型的核心逻辑，然后展开 Calibre、Pandoc、极简脚本以及各类在线工具的实际操作和取舍，最后是转换完以后怎么校验、怎么修复那些“看起来成功但实际不能用”的隐患。适合有整批电子书需要标准化存档的人、想给自己做阅读排版的人、以及需要把资料交给同事或客户、对版面有固定要求的人。

1. EPUB、MOBI 与 PDF 的底层差异：决定选型的第一件事

先理解一件事：电子书转 PDF 不是“格式互换”，而是一次“重新排版”。这种重排的复杂度，完全取决于源格式与 PDF 的排版模型差异。

1.1 流式排版与固定版式到底差在哪

EPUB、MOBI、AZW3 这类电子书格式，用的是“流式排版”模型。你可以把它想象成流水线上流动的液体——文档内部没有“页”的概念，只有一段一段的 XHTML 内容加 CSS 样式。阅读器根据屏幕宽度、字体大小、行间距实时重新排列文字，这叫 reflowable（可重排）。

PDF 正好相反，它内部记录的是“每一个字形、每一张图片放在页面坐标系的哪个具体位置”。所以 PDF 适合做固定版式（fixed layout），比如印刷排版、合同单据、设计稿。PDF 屏幕上是长什么样，打印出来就是什么样，任何设备打开都一致。

所以从 EPUB 转 PDF，本质上是把“流水”倒进一个固定大小的“容器”：需要决定纸张规格（A4、A5、Letter，还是 6 寸阅读器屏），需要计算每页能容纳多少行，需要处理代码块、表格、图片如何分页，需要处理原来适应手机竖屏的封面图如何适配横版页面。转换引擎做不做这些事、做得好不好，直接决定你拿到的 PDF 是“能读”还是“能交付”。

1.2 为什么直接改后缀名一定会翻车

你把.epub改成.pdf，操作系统读取文件头时发现它内容仍然是 ZIP 压缩包结构，里面还是一堆.xhtml和.css，PDF 阅读器根本不会按 HTML 去解析渲染，绝大多数软件直接拒绝打开，少数软件强行打开了也只能看到乱码或者空白页。

同理，.txt改成.pdf、.mobi改成.pdf，都是没意义的。格式转换必须经过“解析源格式 -> 构建中间文档树 -> 用目标引擎重新渲染”这条路径，不是后缀改名能替代的。

我遇到过一些朋友用手机自带的“导出为 PDF”功能处理 EPUB，这类入口大多只是把当前阅读视图做个屏幕截图式的快照，出来的 PDF 页面尺寸混乱，文字清晰度差，还不能选中复制。如果仅自己临时看还行，想长期存档或交付，就不合适。

1.3 “转 PDF”在不同场景下根本不是一回事

同样是“电子书转 PDF”，场景不同，优化目标完全不同。

• 场景一：阅读。目标是 6 寸、7 寸、10 寸等设备的屏幕不吃力，字号大、行距宽，页面跟手，适合转成 PDF 后在平板或电纸书上用笔记软件标注。
• 场景二：存档。目标是版式稳定、文件不过度膨胀，日后换任何设备都能看，适合按 A4 或 A5 排版。
• 场景三：交付/打印。可能是老师给学生发讲义、程序员给同事发技术手册、编辑给作者返排版稿。页面要有页码、有目录书签、字体必须嵌入，图片不能太糊也不能太大。

这三个场景需要的参数完全不同。很多人上来就问“用什么工具最好”，其实是问错了问题。先定场景，再选工具，后面才不至于反复折腾。

2. 工具选型背后的真实逻辑：不是“哪个最强”，而是“谁匹配你的输入和输出”

市面上一搜“电子书转PDF”的工具，五花八门：Calibre、Pandoc、PDF 24、ilovepdf、Smallpdf、Kindle 自带导出、Microsoft Print to PDF 之类。要理解为什么某些场景我应该用 A 而不是 B，需要看一条主线和两条支线。

2.1 输入格式决定一切

从输入格式出发，可以分成下面几类，选型方向完全不同。

注意最后一类比较特殊：本身就是 PDF，但内容是扫描图片。这类“转 PDF”的需求实际是 OCR 识别，要的是加一个可检索文字层，不是格式转换工具能解决的。

2.2 转换引擎的两条技术路线：渲染型与重建型

把工具拆开看，真正干活的引擎有两大流派。

渲染型引擎常见于各种在线 PDF 转换器、办公软件“另存为 PDF”。做法是把文档内容当成画布逐页绘制，版面是在内存里实时算出来的。优点是对不规则排版容错性高，缺点是可控参数少，目录书签经常丢，中文嵌入字体偶发缺字。

重建型引擎的典型代表是 Calibre 的 ebook-convert。它会先把电子书内容解包，解析为内部统一的“图书模型”（逻辑上就是从 XML、CSS 抽象出文档结构），然后针对 PDF 输出模块重新布局。这种路线的好处是可控性强：可以指定输出 profile、字体嵌入策略、页面边距、目录层级。缺点是多少会改变原书风貌，因为它是“重建”而不只是“覆盖”。

我的习惯是：批量电子书、对版式有标准化存档需求，一律用重建型引擎，宁可多花三分钟设置，不跟在线工具较劲。

2.3 工具的真身要先搞清：很多国产“PDF 编辑器”其实调用的还是第三方引擎

选型时还有个坑——“XX PDF 编辑器”往往只是套壳界面，真正进行格式重建的仍是嵌入式引擎。这些产品对单文件、快速转换有帮助，界面友好，但遇到批量任务、复杂目录层级、字体不完全嵌入时，就难以控制。

用它们处理零散文件没什么问题。但如果你的目标是“建立一套自己的转换工作流”，建议主工具选择可脚本化的 CLI，比如 Calibre 的ebook-convert或 Pandoc。图形界面用来看效果、命令行用来批量跑，这是专业玩家和个人用户的分水岭。

3. Calibre 是绕不开的主力：转换管线与关键参数怎么调

Calibre 不只是“电子书管理器”，它内置的ebook-convert是最成熟的 EPUB/MOBI/AZW3 转 PDF 引擎之一。我用它处理过上万本电子书，下面这些是真正影响成品质量的核心点。

3.1 管线里发生了什么：解包、清洗、重排版

在有图形界面下，找到“转换书籍”，它实际上会走这几步。

第一步是“解包”。EPUB 本质是 ZIP 包，里面常见的有OEBPS/text下的 XHTML 文件、CSS、图片和toc.ncx/nav.xhtml。Calibre 要把这些文件读进来，建立一棵完整的逻辑文档树。

第二步是“清洗与标准化”。这一步会清理无效标签、合并/修复错误的 CSS、把相对路径的图片重新定位。很多网上下载的电子书存在标签不闭合、CSS 中字体单位错误、图片路径断裂的问题，Calibre 会尽力修复。

第三步是“按目标 profile 重排出 PDF”。这里涉及页面尺寸、字体替换、页边距、分页逻辑。这一步的参数就是你在转换对话框里看到的那一堆选项。

所以，Calibre 不是简单地“把 EPUB 逐页画出来”，而是给你一个可以干预内容结构的转换引擎。

3.2 输出 profile、字体嵌入与页面边距，实际怎么填

先说输出 profile。Calibre 里有很多预设：Tablet、Kobo、Kindle、Sony Reader、A4、A5、Letter 等。这个选项会决定最终 PDF 的页面尺寸和默认边距。不要偷懒一律选默认，最好按你的用途来：

• 存资料/打印：选A4，边距建议 15mm 到 20mm，正文用小四或五号对应的点阵（10.5pt 到 12pt）。
• 平板阅读/手写批注：选你平板的分辨率对应的 profile，比如Tablet或10 寸类预设，边距可以放大到 20mm 左右，留批注空间。
• 电纸书阅读：如果设备是 6 寸，那别转换到 A4 再缩放，直接选小屏 profile，否则字会小到没法看。
• 如果预设里没有合适的，可以自定义“自定义页面大小”，单位默认是点（point）。A4 是 595 x 842pt，想要 16 开（185mm x 260mm）就是约 524 x 737pt。

字体嵌入这一项一定要勾选“嵌入所有使用到的字体”。PDF 阅读器在打开文件时，如果找不到对应字体，会用自己的字体替代，中文替代的结果就是字形错位、标点乱跳。嵌入字体后，文件里直接带着字体子集，任何设备打开都一样。代价是文件体积增大几 MB，但对于以存档和交付为目的的转换，值得。

页面边距建议不要小于 10mm。PDF 打印时很多打印机不支持无边距打印，而且电纸书、平板截边裁切也容易吃掉页面内容。转完想排版更紧密，可以后续用工具统一裁剪，但一开始就太小会丢内容。

3.3 目录书签：很多人忽略的关键设置

很多电子书的目录是内部链接，在 EPUB 阅读器里可以点击跳转，但转成 PDF 后，如果 Calibre 没有把导航结构转成 PDF 书签（bookmarks），你拿到的是一个“没有目录”的大文件，只能一页页翻。

Calibre 转换对话框里，有一个“PDF 输出”相关选项，里面有“在 PDF 中生成书签”或类似开关。同时，源 EPUB 的目录级别要设对。常见问题是目录层级过深，书签里全是三级、四级条目，看得人头疼；或者目录过浅，只有几个章节。

我一般会先用 Calibre 的“编辑书”功能检查toc.ncx或nav.xhtml，把层级控制在二级以内再转。书籍本身目录混乱的，用 Calibre 自带的“转换时使用启发式处理”能修复一部分，但也不万能，重要文档还是要人工核。

3.4 用命令行走一遍批量流程

图形界面适合调参和临时转换，但遇到成批的几十上百本书，还是命令行舒服。Calibre 的命令行工具在安装目录里，例如：

ebook-convert input.epub output.pdf \ --output-profile a4 \ --paper-size a4 \ --margin-top 20 \ --margin-bottom 20 \ --margin-left 15 \ --margin-right 15 \ --base-font-size 11 \ --font-size-mapping 11,12,14,16,18,22,24 \ --pdf-add-toc \ --pdf-page-numbers \ --extra-css "body { text-align: justify; }"

几个参数解释一下：

• --output-profile决定页面大小。--paper-size a4在某些版本里是另一个入口，二者可以配合。
• --base-font-size直接决定正文基础字号。电子书原样式里的em、百分比都会依据它换算。
• --pdf-add-toc是在 PDF 侧加入书签目录，默认不一定开启，显式声明比较稳妥。
• --extra-css是终极武器，可以覆盖源书里不合理的样式。很多源 EPUB 正文是左对齐，加上text-align: justify后两端对齐阅读体验会好很多。

命令行方式的好处是可以写一个循环批量跑：

for f in /path/to/books/*.epub; do ebook-convert "$f" "${f%.epub}.pdf" \ --output-profile a4 \ --pdf-add-toc \ --base-font-size 11 done

注意 Windows 下不要直接在 cmd 里跑这个for语法，建议在 PowerShell 或者直接写 Python 脚本调用subprocess。别问我怎么知道的，我在 cmd 里被卡到怀疑人生。

4. 不同源格式的处理路径：MOBI/AZW3、TXT、网页导出各有各的坑

4.1 Kindle 系格式：先解包再转换，别跳过中间层

MOBI 和 AZW3 的结构比 EPUB 复杂。AZW3 内部其实也是类似于 EPUB 的 HTML 布局，但外层还包了一层 Kindle 专用容器，有 DRM 保护时尤其麻烦。处理路线通常是：

1. 先用 DeDRM 工具（如果书籍是你自己有权益的文件）去除 DRM，得到无保护的 AZW3/MOBI。
2. 用 Calibre 先转成 EPUB，作为中间清洗层。
3. 检查一遍 EPUB 效果，再转 PDF。

有人图省事直接从 MOBI 转 PDF，出来排版经常有意外。因为 Kindle 格式里的样式、图片对齐方式跟标准 EPUB 有差异，转一次 EPUB 等于先用 Calibre 的清洗模块把内容规范化一次，很多 MOBI 遗留的怪异间距会被修干净。

另外，MOBI 的老旧格式（Mobipocket 7）不支持很多现代 CSS 属性，从它转 PDF 时，标题样式和字体效果会劣化。先转成 EPUB 再转 PDF，至少能把损失控制住。

4.2 TXT / Markdown：没有结构就造结构

纯文本是最容易被低估的输入。直接扔给浏览器打印或丢进 Word 转 PDF，搞出来的问题是：没有层级标题、没有目录、段首缩进参差不齐。

如果源文件是 TXT，我建议先做一个正则清洗步骤，常见任务包括：

• 把章节标题统一格式，比如匹配“第x章”加上换行标记；
• 处理全角/半角空格；
• 把文中的 URL 补全为可点击的超链接（如果后续转成 PDF 有交互需求）；
• 处理编码问题。很多 TXT 是 GBK/GB18030 编码，直接读成 UTF-8 会乱码。得先iconv转换编码再进管线。

Markdown 则可以用 Pandoc。Pandoc 能从 Markdown 生成 PDF，但走得是 LaTeX（默认）或 WeasyPrint 等引擎。中文场景下，LaTeX 路线需要配置中文支持，推荐用 XeLaTeX，再指定一个中文字体。来一个最小示例：

pandoc input.md -o output.pdf \ --pdf-engine=xelatex \ -V mainfont="Noto Serif CJK SC" \ -V geometry:margin=2cm \ --toc

在 Linux 上需要先安装 TeX Live 和中文字体。Windows 上比较麻烦，建议改用 WSL 或在 Docker 里跑 Pandoc，如果在 Windows 原生环境搞，字体配置和 LaTeX 宏包的坑能把人劝退。

如果你对排版没有刚需，更简洁的方案是先把 Markdown 渲染成 HTML，再用无头浏览器（Chrome headless）打印成 PDF。后面的章节会讲到打印路径。

4.3 网页/长文导出：浏览器打印的黄金配置

有时源内容其实是网页。比如你有一篇 CSDN 文章、一个帮助文档、或者一份在线教程，想存成 PDF。“网页右键打印”每个人都会，但打印出来的东西往往带着侧边栏、广告位、无用的页眉页脚。要控制质量，正确做法不是直接打印，而是先“清理页面”再“打印”。

可以用无头 Chrome：

google-chrome --headless --disable-gpu \ --print-to-pdf=output.pdf \ --no-pdf-header-footer \ --print-to-pdf-no-header \ URL

参数含义很直白。如果页面内容需要滚动懒加载，无头浏览器一次拿不到全部内容，就得用脚本先滚动加载再触发打印，或者用 Puppeteer 之类的库控制。这是另一个大话题，此处只提醒一点：--no-pdf-header-footer一定要写，否则页面底部会出现一堆时间戳和链接地址，打印出来很难看。

如果你的页面有自己的打印样式（@media print），打印结果会好很多。没有的话，也可以临时注入 CSS 隐藏不需要的元素。比如：

@media print { nav, header, footer, .ad, .sidebar { display: none !important; } .content { width: 100%; margin: 0; } }

4.4 “转曲”是什么？为什么广告印刷店总提这两个字

热搜词里出现“pdf转曲”和“pdf图片中文设置”。前者是印刷行业术语，意为把 PDF 里的文字内容转换成矢量轮廓（curves），这样无论字体有没有嵌入、对方电脑是否装有字体，文件显示都不会变形。如果你要把电子书关键页拿去打印店印刷，店家往往会要求“文字转曲”。

印前转曲可以使用 Adobe Acrobat 的“印前检查”功能，或者用专业的 PDF 工具。普通阅读场景不转曲的好处是文字还能选中、检索、复制，转曲后就彻底变成图形了。注意别把阅读版 PDF 拿去做转曲，会失去文本层。

“PDF图片中文设置”大概率是扫描或图片转换后文字识别语言选错了。如果PDF里中文不能搜索或复制，大概率缺 OCR 文字层，后文会专门讲校验方法。

5. 批量转换后的三关校验：目录、文字层、文件体积

转换完成不等于交付完成。我在这一步吃过太多亏——肉眼看了前几页没问题，发给别人后才发现某些章节图片缺失、目录书签空白、文件名乱码。所以每次都执行下面几关。

5.1 第一关：目录书签是否完整、层级是否可读

用 PDF 阅读器打开文件，看左侧书签。如果一本 300 页的书书签只有 3 条，那基本是转换时没识别到目录结构。如果书签层级乱到“第3章”出现在“第1章”下面，说明源 EPUB 的导航层级有问题。

要用命令行验证目录，可以用pdfinfo输出的页面信息配合pdftk或mutooldump 书签。比如mutool info -m output.pdf会打印基础元数据。复杂目录可以用mutool show output.pdf outlines查看。不过这属于进阶调试，日常操作时用阅读器肉眼检查就够了。

如果不满意目录，直接在 Calibre 里改好源书的目录再转一次，这一步效率远高于在 PDF 里手工调书签。

5.2 第二关：有无文字层、文字能否被搜索和复制

PDF 分两种：带文字层的和纯图片的。转换工具生成的 EPUB/MOBI 转 PDF 基本都带文字层——文字是真实字符。但如果你从“扫描版电子书”或“图片型 PDF”转出来，可能是无文字层的图片流，搜索关键词找不到。

检查方法最简单：用 PDF 阅读器 Ctrl+F 搜一个书里必然出现的词，比如作者名或一个专业术语。如果搜不到但肉眼能看到，就说明没有文字层。再高端一点，用命令行工具pdftotext output.pdf - | head -30看能否提取出正文前三十行。如果没有输出，那你拿到的是一个“假 PDF”。

对于扫描版内容，只有一个解法：OCR 加文字层。工具可选 Tesseract、Adobe Acrobat 的“扫描与 OCR”、ABBYY FineReader。中文 OCR 的话，Tesseract 需要下载chi_sim语言包，识别精度比 Acrobat 低一截，胜在免费可控。用 Acrobat 处理全中文扫描书，识别质量在 95% 以上，但遇到繁体或竖排还会拉胯。竖排古籍类不建议普通 OCR，那不是转格式能解决的。

5.3 第三关：文件体积与图片是否失控

电子书里的插图通常压缩过（JPEG 或 WebP 居多），转成 PDF 时如果 Calibre 按原始分辨率放了进去，文件体积会爆炸。一本 100 张彩图的漫画书，转出来可能超过 300MB。

处理思路是转换前先对原书图片做统一压缩。比如用 Python 脚本或mogrify把超过 2000px 的图缩到 1600px，统一转成优质 JPEG，再回装 EPUB，最后再转 PDF。

也可以在 Calibre 转换设置的“PDF 输出”里指定 JPEG 质量，但请注意，这只影响输出图的质量，并不改变原图分辨率。体积还大就得源头压缩。

如果已经生成了 PDF 但体积太大，最直接的方法是用 Ghostscript 重新压缩：

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 \ -dPDFSETTINGS=/ebook \ -dNOPAUSE -dBATCH \ -sOutputFile=output_small.pdf input.pdf

-dPDFSETTINGS=/ebook是一个针对电子书场景的预设，会适度降采样图片。对纯文字文档，体积通常能降 50% 以上，且肉眼几乎无损。如果你要“无损压缩”，就不要用 Ghostscript 的预设，而应自己指定更高的分辨率阈值，比如-dColorImageResolution=150。

5.4 用三个命令完成快速体检

在我自己的流程里，转换后会自动跑一遍下面三个命令：

pdfinfo file.pdf # 看页数、页面尺寸、PDF 版本、是否有加密 pdftotext file.pdf - | wc -l # 统计文字层是否正常 mutool info -m file.pdf # 深挖字体嵌入情况与页面资源

页数和页面尺寸好理解。文本行数如果为 0 或极低，说明 PDF 不是正常文字型文件。字体嵌入信息则可以让你确认没有“假字体替换”。这些命令在 Poppler 工具集和 MuPDF 工具集里都有，Linux 下安装方便，Windows 下用 WSL 也很顺。

6. 转 PDF 后依然翻车的重灾区与修复技巧

即使转换器跑通了，也经常出现各种“不是技术性错误，但实际不可用”的问题。这块的内容属于经验之谈，常规文档里少有人系统讲。

6.1 代码块折行与缩进丢失，是技术类电子书的头号难题

技术类电子书有大量代码片段，在 EPUB 里代码块通常会放在<pre>标签中，用等宽字体显示。但转 PDF 时，如果pre块的宽度超过页面可用宽度，要么被截断、要么强制折行。折行的代码缩进全乱，完全没法读。

我的处理方式是按源码层级来：在转 PDF 以前，用 Calibre 的“编辑书”把 CSS 里的pre块字体调小，并加white-space: pre-wrap; word-wrap: break-word;以允许必要时折行。字体大小可以从 0.8em 调低到 0.65em 左右，尽量让代码在 A4 版式下一行塞得下。

如果书里的代码是图片形式（有些 PDF 电子书为了省事把代码渲染成图片），那就无解了，只能看原图清晰度。

给一组常用的pre覆盖 CSS：

pre { font-family: "Noto Sans Mono CJK SC", "JetBrains Mono", Consolas, monospace !important; font-size: 0.6em !important; line-height: 1.4; white-space: pre-wrap; word-wrap: break-word; }

把它填进 Calibre 转换选项的“额外 CSS”里，代码块就不会把版面撑爆。

6.2 竖排书、直排 EPUB 转出来方向全是错的

部分中文古籍、港台书籍使用纵向排版。EPUB 里通过writing-mode: vertical-rl或-epub-writing-mode: vertical-rl实现竖排。但 Calibre 的 PDF 输出引擎对竖排的支持一直不算好，转出来经常出现文字方向还是横的、标点位置错乱的情况。

坦白说，竖排文本转 PDF 没有完美的免费方案。比较实用的路线是：

1. 用 Calibre 把 EPUB 转成带有文字版的 PDF，但并不指望排版完美；
2. 将 PDF 放入支持竖排阅读的阅读器中阅读；
3. 若必须打印纸质竖排书，用 Adobe InDesign 之类专业排版软件人工重排，这是纯手工活。

对大多数普通用户，竖排转横排才是常态。如果目标只是“能在 PDF 上标注”，横排输出够用了。

6.3 页面边距想裁掉怎么办：专业裁剪工具不能少

有些源 EPUB 转出的 PDF 边距非常宽，看起来像书的内容可怜巴巴地挤在页面中间。重头转一次又浪费时间。这时候用 K2pdfopt 或者 Briss 做自动裁剪是更高效的选择。

K2pdfopt 本身就很神奇，它能把 PDF 重排成适合 Kindle/手机屏幕的版式。它的优化逻辑是“分析页面布局，把正文区块切出来，再在目标页面上重新排布”。

不过提示一句：K2pdfopt 的界面很丑，参数也多得吓人。如果只是简单裁边，用 Briss 这种图形化工具选中内容区域输出就行。我的经验是，给 PDF 裁边时留 2-3mm 的安全边距，别裁到页眉页码，否则后续要自己补页眉就麻烦了。

6.4 拆分、合并与加页码：小操作，大坑

如果转换出来的 PDF 要拆分章节、合并到其他文件或补页码，不要用在线工具，因为涉及上传下载，且很多在线工具的隐私策略不明确。本地操作，推荐用qpdf或pdftk。

合并两本 PDF：

qpdf --empty --pages a.pdf b.pdf -- out.pdf

提取第 10 到 20 页单独保存：

qpdf a.pdf --pages . 10-20 -- part.pdf

加水印、加页码可以通过mutool或pdftk。其中mutool的 watermark 命令可以把文字作为水印打在每一页的固定位置。这个能力在批量给电子书打上“内部资料”标识时非常有用。

7. 工作流沉淀：从零散资源到可检索的个人 PDF 资料库

做完整条链路之后，你会发现最值钱的不是某一个工具，而是一套稳定的流水线。我自己目前的工作流，大致是下面这样：

输入资源统一放到文件夹，分门别类存放。EPUB/AZW3/MOBI 系列先进 Calibre 管理；需要转为 PDF 的，先按用途打上标签（“平板阅读”“打印”“存档”“交付”），再跑一段预设好的转换脚本。转换完的 PDF 文件进入独立目录，文件名统一用“书名 - 作者”的规范命名，像深入理解计算机系统 - 兰德尔.E.布莱恩特.pdf。

做完以后用pdftotext抽正文建倒排索引，这样以后想找某段话，不需要一本本打开 PDF，直接全文检索几十秒就能定位到具体书。我用recoll做个人文档全文索引，对中文支持不错，也可以自己写 Python 脚本提取关键词建立简单的索引库。这一步对资料量大的情况收益极高。

补一个命名习惯的注意点：文件夹内如果包含大量 PDF 文件名带有特殊字符（/、?、*等），在 Windows 环境处理时会报错，Linux 下没问题。转换前先做一次文件名清洗会减少很多意外。

实际操作中我还发现一个细节：同一本书从 EPUB 转换时，最好在 Calibre 里把“输入格式”设置为原始格式而不是“自动”。因为 Calibre 在自动检测时偶有偏差，遇到容器内格式特殊的情况会选错解析器。手动指定可以规避一部分解析问题。

如果一本书图文混排且排版复杂，比如杂志类、画册类 EPUB，建议不要强行转 PDF。EPUB 本来就不适合这类内容，转出来往往是灾难。这类资源若有原生 PDF 版应直接找原生版，不必为格式折腾。

8. 关于字体、页面尺寸和电子书“外观”的一点心得

最后聊点不那么硬核但实际体验影响很大的内容。

转 PDF 后觉得丑，十有八九是字体问题。中文书籍转 PDF，正文我一般指定宋体或思源宋体，标题用思源黑体，代码用等宽字体。电子书源文件里如果声明了某种西文字体而你没有装，Calibre 会用默认字体替换，可能不会报错，但版式会悄悄变化。

给 Calibre 指定默认中文字体时，可以通过--extra-css把 font-family 链写好：

body { font-family: "Noto Serif CJK SC", "Source Han Serif SC", "SimSun", serif; } h1, h2, h3 { font-family: "Noto Sans CJK SC", "Source Han Sans SC", "Microsoft YaHei", sans-serif; }

如果你的目标是打印，衬线字体会更有阅读感；屏幕阅读则无衬线更清晰。不要迷信“哪个字体高级”，关键是让每个打开文件的人看到的字形一致。

页面尺寸的执念也要放下。A4 是打印标准，但做成 PDF 在手机上看绝对痛苦。我现在的习惯是：同一本书，如果既要在平板批注又可能要打印，就生成两版，分别以“10 寸平板 profile”和“A4”输出，文件名后缀标注清楚。存储成本不高，但使用体验提升巨大。

最后分享一个很多人没意识到的小技巧：转换完成后，在 PDF 元数据里填写好标题、作者和关键词，这样在文件管理器里搜索、在 PDF 阅读器里归类和后续全文检索都会高效很多。用命令直接写：

exiftool -Title="书名" -Author="作者" -Subject="分类;关键词" file.pdf

这一步五分钟的事，却能给整个 PDF 管理流程省下很多时间。

电子书转 PDF 的门槛不高，但天花板很高。把每一步的关键点理解清楚，你不需要再追着新版工具跑，因为无论工具怎么换，底层要处理的问题始终是这几个：源格式解析、版面重排、字体嵌入、目录结构、文字层完整性、文件体积控制。把这条链路跑顺，你的 PDF 就不再是“凑合能看”，而是真的能作为资料长期保存的东西。