企业官网建设流程全解析

1. 一份电子书为什么要做三种格式

拿到《高性价比人生指南》这个标题的时候，我第一反应不是"这书讲什么"，而是"为什么是PDF、EPUB、HTML三种格式一起发"。这个组合本身就透露了很多信息——它不是随手导出的一个文件，而是针对不同阅读场景做了分发设计。我做过不少电子书排版和分发的工作，深知多格式并行意味着额外的工作量：字体嵌入、目录锚点、分页控制、响应式布局，每一项都要单独调。愿意为一个内容产品做三套输出，说明作者对"读者在什么设备上读"这件事是有预期的。

先把三种格式的定位说清楚，这是理解整个项目的基础。PDF的核心价值是"版式锁定"，你在任何设备上打开，看到的行距、字号、图文位置都一模一样，适合需要精确呈现排版的内容，比如带图表、带引用框、带固定章节扉页的读物。EPUB是流式排版，文字会跟着屏幕大小重排，字号可以调，适合手机、墨水屏这类小屏设备长时间阅读，它的本质是一个打包好的网页集合。HTML则是直接给你一个可以在浏览器里打开的页面，不需要任何阅读器，链接可点、目录可跳，适合在电脑上快速翻阅或者分享给不想装软件的人。

这三种格式覆盖的是三类完全不同的使用场景：PDF对应"我要一份完整、正式、可存档的版本"，EPUB对应"我要在通勤路上用手机慢慢读"，HTML对应"我只想快速扫一眼或者转发链接"。一个内容产品同时提供这三样，等于把读者的进入门槛降到了最低——你不用先决定用什么设备，先拿到手再说。这个思路本身就很"高性价比"，和书名形成了呼应。

我在实际操作中遇到过太多反例：只发PDF，结果读者在手机上放大缩小看得眼睛疼；只发EPUB，结果有人想要打印出来做笔记却发现排版全乱；只发网页，结果离线就读不了。三格式并行的成本确实高，但换来的是"任何人、任何设备、任何场景都能读"，这笔账对于一份面向大众的指南类内容来说是划算的。接下来的内容，我会把这套三格式方案从制作到分发的完整链路拆开讲，包括每种格式在制作时最容易翻车的地方，以及我是怎么处理这些问题的。

2. 三种格式的定位差异与选型逻辑

2.1 PDF：版式确定性优先，但要接受它的"死板"

PDF的本质是一份"打印描述文件"，它记录的是每个元素在页面上的绝对坐标。这带来一个巨大的好处：所见即所得。你在电脑上排好版，发给任何人，对方看到的和你看到的一模一样。对于《高性价比人生指南》这类可能包含章节扉页、重点摘录框、对比表格的内容，PDF能保证这些设计元素不走样。

但PDF的"死板"也是它最大的坑。它不会根据屏幕重排，在6寸手机屏上，一页A4大小的PDF缩到能看全，字就小到没法读；放大到能读，又得左右拖动。我见过不少人做的PDF电子书，在电脑上看着挺美，一到手机上体验直接崩掉。所以做PDF版本时，页面尺寸的选择非常关键。

我的做法是：如果这份内容主要在电脑和打印场景使用，用A4；如果希望手机也能勉强读，用接近手机比例的尺寸（比如16:9或者更窄的竖版），并且把正文字号放大到至少11pt，行距拉到1.5倍以上。牺牲一点每页的信息密度，换手机端的可读性，对于指南类内容来说是值得的。另外，PDF一定要做书签目录，这是很多人忽略的细节——没有书签的PDF，读者想跳到某一章只能靠滚动条硬拖，体验极差。

2.2 EPUB：为小屏和长读而生，流式的代价是控制力

EPUB是流式格式，它的排版逻辑更接近网页：文字是"流"的，阅读器根据屏幕宽度决定每行放多少字、一页放多少行。读者可以自由调字号、调字体、调行距、切换夜间模式。这对手机和墨水屏用户极其友好，也是它成为主流电子书格式的原因。

代价是你对版式的控制力大幅下降。你在EPUB里设的"这段文字靠右对齐、旁边放一张图"，到了某些阅读器上可能变成图片单独占一行、文字跑到下面。EPUB的兼容性是个老大难问题：不同阅读器对CSS的支持程度参差不齐，同一个文件在不同设备上可能呈现不同效果。我踩过最典型的坑是字体嵌入——你在EPUB里指定了一个特殊字体，结果阅读器不支持，自动回退到系统默认字体，整个设计感就没了。

所以做EPUB的核心原则是：不要依赖精细排版，把结构做扎实。标题层级用标准的h1/h2/h3标签，目录用EPUB内置的导航文档（nav.xhtml），图片用相对路径引用并控制好尺寸。样式上尽量用最基础的CSS，别玩花活。这样虽然看起来朴素，但在任何阅读器上都不会崩。

2.3 HTML：零门槛的"即开即读"，适合分发和快速浏览

HTML版本的价值在于零安装、零等待。读者拿到一个HTML文件，双击就能在浏览器里打开，不需要装任何阅读器。目录可以做成锚点链接，点一下直接跳转；重点内容可以做成折叠块；甚至可以在页面里加一个简单的搜索框。对于"我就想快速看看这书讲什么"的读者，HTML是最低摩擦的入口。

但HTML也有它的局限：它本质上是给"屏幕阅读"设计的，不适合打印，也不适合离线长时间阅读（除非你把它做成单文件并处理好所有资源引用）。我的经验是，HTML版本应该做成单文件——所有CSS内联、图片用base64嵌入或者干脆不放图，这样读者保存一个文件就能带走全部内容，不会出现"图片裂了"的尴尬。

下面这张表是我总结的三种格式的选型对照，做内容分发时可以直接参考：

理解了这三者的定位差异，后面的制作流程才有意义。选型不是"哪个好"，而是"哪个场景用哪个"，三格式并行的意义就在于不逼读者做选择。

3. 从一份源文件到三套输出的制作链路

3.1 用Markdown做单一内容源，避免三份内容各改各的

三格式并行最大的风险是内容不同步。如果PDF改了一处、EPUB忘了改、HTML还是旧版，读者拿到的三个版本内容不一致，这是灾难。我见过有人分别用Word做PDF、用Sigil做EPUB、用Dreamweaver做HTML，结果三份文件的内容对不上，维护成本高到崩溃。

正确的做法是单一内容源。我强烈建议用Markdown写正文，因为Markdown是纯文本，结构清晰（标题、列表、引用、加粗都有标准语法），而且可以转换成任何格式。具体链路是：Markdown源文件 → 用Pandoc转EPUB和HTML → 用排版工具（比如LaTeX或者专门的PDF生成工具）转PDF。这样内容只维护一份，改一处，三处同步更新。

Markdown写作时有几个约定要提前定好，否则转换时会出问题。第一，标题层级严格用#到######，不要用加粗假装标题，因为转换工具靠标题标签生成目录。第二，图片用标准语法并统一放在一个assets目录，路径用相对路径，这样转EPUB时图片能正确打包。第三，表格和代码块用标准语法，Pandoc对标准Markdown的表格支持最好。第四，章节之间用水平线或者明确的标题分隔，方便PDF分页。

我实际用下来，Pandoc是这条链路里最稳的工具。它一条命令就能把Markdown转成EPUB和HTML，而且支持自定义CSS和模板。下面是我常用的转换命令：

# Markdown 转 EPUB，指定元数据和样式 pandoc guide.md -o guide.epub \ --metadata title="高性价比人生指南" \ --metadata author="某作者" \ --toc --toc-depth=2 \ --css=epub-style.css \ --epub-cover-image=cover.jpg # Markdown 转单文件 HTML，内联所有样式 pandoc guide.md -o guide.html \ --standalone \ --toc --toc-depth=2 \ --css=web-style.css \ --embed-resources

--toc自动生成目录，--toc-depth=2表示目录只到二级标题，避免目录太长。--embed-resources是关键参数，它把CSS和图片全部内联进HTML，生成的就是一个可以单独带走、不会裂图的单文件。EPUB那边--epub-cover-image指定封面，阅读器的书架上会显示这张图，细节但重要。

3.2 PDF这一环：为什么我不建议直接用浏览器打印

很多人做PDF的方式是"HTML写好后用浏览器打印成PDF"，简单是简单，但问题一堆。浏览器打印的分页控制很弱，经常出现标题孤零零留在页底、表格被拦腰截断、图片跨页撕裂的情况。而且浏览器打印的页边距、页眉页脚很难精确控制，做出来的PDF一看就是"网页打印版"，不够正式。

我的做法是用专门的排版工具生成PDF。如果内容以文字为主，用LaTeX（通过Pandoc的PDF引擎）能得到非常专业的排版效果，章节自动分页、页眉页脚、目录页码全都规范。如果不想碰LaTeX，用一些支持Markdown直接导出PDF的排版软件也行，关键是它们提供分页控制——你可以指定"每个一级标题另起一页"、"表格不允许跨页断开"这类规则。

PDF制作里我最在意的三个细节：一是字体嵌入，必须把用到的字体完整嵌入PDF，否则在没装该字体的设备上会回退成默认字体，排版全乱；二是书签，用工具生成PDF时确保标题层级被识别为书签，读者能通过书签面板快速跳转；三是超链接，目录里的条目要能点击跳转到对应章节，这个在生成时勾选"创建内部链接"即可。这三点做到，PDF的可用性就上了一个台阶。

3.3 EPUB的兼容性打磨：在三个阅读器上各测一遍

EPUB做完不能只看一个阅读器的效果。我的标准流程是至少在三个不同内核的阅读器上各打开一次：一个桌面端（比如Calibre自带的阅读器）、一个手机端、一个墨水屏设备或者模拟器。重点看四件事：目录能不能正常展开、图片有没有变形、标题层级显示是否正确、长段落有没有出现奇怪的断行。

我踩过最深的坑是CSS里的固定宽度。早期我在EPUB的样式里给图片写了width: 600px，在电脑上看着正好，到了手机阅读器上图片直接溢出屏幕，右边被裁掉。后来改成max-width: 100%; height: auto;，图片就自动适应屏幕宽度了。这个教训适用于EPUB里所有的尺寸设置——永远用相对单位，别用绝对像素。

还有一个容易被忽略的点是EPUB的元数据。标题、作者、语言、封面，这些信息要填完整。语言字段（language）尤其重要，填错了某些阅读器的断词和排版规则会出问题。中文内容要填zh-CN，这个细节很多人不知道，但影响实际阅读体验。

4. 排版细节里那些真正影响阅读体验的地方

4.1 正文字号、行距与每行字数的黄金组合

电子书排版里，最影响阅读舒适度的不是字体好不好看，而是每行放多少字。排版界有个经验值：中文正文每行25到35个字最舒服，超过40个字眼睛在换行时容易串行，少于20个字则频繁换行、节奏被打断。这个数字在PDF里由页面宽度和字号共同决定，在EPUB和HTML里则由阅读器宽度和字号决定。

我的处理方式是：PDF里把正文区域宽度控制在能放30字左右，字号11到12pt，行距1.5到1.6倍。EPUB和HTML里不锁死字号（让读者自己调），但通过max-width限制正文容器的最大宽度，比如max-width: 38em，这样在大屏上也不会出现一行拉得老长的情况。行距统一用line-height: 1.7，中文比英文需要更宽松的行距，1.5对中文来说偏挤。

段落间距也是个细节。中文排版传统是首行缩进两字符、段间不留空，但屏幕阅读的习惯更接受段间留空、不缩进。我两种都试过，屏幕阅读时段间留空（margin-bottom: 1em左右）的视觉节奏更清晰，读者不容易看串段。这个选择没有绝对对错，但要在三种格式里保持一致，别PDF缩进、网页留空，读者切换格式会觉得别扭。

4.2 目录、锚点与跨格式的跳转一致性

目录是电子书的骨架，但三种格式的目录实现方式完全不同。PDF靠书签，EPUB靠内置的nav文档，HTML靠锚点链接。做的时候要确保三套目录的条目和层级完全一致，否则读者在PDF里看到五章、在网页里看到六章，会困惑。

用Pandoc的--toc参数能自动从标题生成目录，这是最省事的方式。但要注意，自动生成的目录锚点ID可能包含中文，某些老浏览器对中文锚点支持不好。我的处理是给每个标题手动加英文ID，或者在Pandoc里用--id-prefix统一加前缀。HTML版本里，目录条目要能点击跳转，跳转后最好有个"返回目录"的浮动按钮，长文档里这个按钮能省很多滚动操作。

EPUB的目录还有个特殊要求：必须有一个独立的nav.xhtml文件（EPUB3标准），里面用<nav epub:type="toc">包裹目录列表。Pandoc会自动生成这个文件，但如果你手动改过标题，记得重新生成，别让目录和正文对不上。我见过EPUB打开后目录是空的，八成就是nav文件没生成或者路径写错了。

4.3 图片与表格在三套输出里的降级策略

图片和表格是跨格式转换最容易出问题的地方。PDF里图片可以是高分辨率、精确位置；EPUB里图片要控制文件大小（整个EPUB包别超过几MB，否则加载慢）；HTML单文件里图片要么内联成base64（文件变大但单文件可带走），要么用外链（文件小但断网就裂）。

我的策略是分级处理：原图保留一份高分辨率版本给PDF用；EPUB用压缩到合适尺寸的版本（宽度控制在800px以内，JPEG质量80左右）；HTML如果追求单文件便携，就用base64内联，接受文件体积变大。表格方面，宽表格在EPUB和手机HTML上会溢出，解决办法是给表格容器加overflow-x: auto让它能横向滚动，或者干脆把宽表格拆成几个窄表。PDF里表格可以完整呈现，但要注意别让表格跨页断开，在排版工具里设置"表格保持完整"。

提示：EPUB里图片的alt属性一定要写，不只是无障碍考虑，某些阅读器在图片加载失败时会显示alt文字，至少读者知道这里原本是什么内容。

5. 分发环节：文件名、体积与打开方式的门道

5.1 文件命名和目录结构，决定了读者的第一印象

三格式并行分发时，文件名混乱是常见问题。我见过发出去的文件叫"最终版.pdf""最终版2.pdf""真的最终版.epub"，读者根本分不清哪个是最新。规范的做法是统一命名规则：书名-版本号-格式.扩展名，比如高性价比人生指南-v1.0.pdf、高性价比人生指南-v1.0.epub、高性价比人生指南-v1.0.html。版本号用语义化版本（主版本.次版本），内容大改升主版本，小修升次版本。

如果打包成一个压缩包分发，目录结构也要清楚：根目录放一个README.txt说明三个文件分别是什么、怎么打开、有什么区别，然后三个文件平铺或者放在pdf/、epub/、html/子目录里。别搞多层嵌套，读者解压后找不到文件是很挫败的体验。README里用两三句话讲清楚"手机看EPUB、电脑看HTML、打印存档用PDF"，比什么都管用。

5.2 体积控制：EPUB别超5MB，HTML单文件别超10MB

文件体积直接影响分发和打开速度。EPUB超过5MB，在一些低端阅读器上打开会明显卡顿；HTML单文件超过10MB，浏览器解析base64图片会变慢。控制体积的核心是图片压缩，文字本身占不了多少空间。

我的压缩流程是：原图先统一缩到最大宽度1200px，然后用工具压到JPEG质量80，PNG只在需要透明背景时用。封面图单独处理，EPUB封面控制在600px宽、200KB以内。做完后检查一遍EPUB包内文件列表，看看有没有误打包进去的临时文件或者重复图片。我遇到过EPUB体积异常大，最后发现是转换时把整个assets目录（包括没用到的原图）都打进去了，清理后体积从12MB降到3MB。

5.3 不同设备的打开方式与常见故障排查

分发出去之后，读者会遇到各种打开问题，提前把排查清单准备好能省很多沟通成本。PDF打不开，多半是阅读器太老或者文件损坏，建议换一个通用阅读器；EPUB导入后目录空白，通常是nav文件问题或者阅读器不兼容EPUB3，可以试试转成EPUB2兼容模式；HTML打开后样式全无，检查是不是把CSS文件单独放出去了而没内联，单文件版本不应该有这个问题。

下面这张排查表是我实际分发中总结的，覆盖了八成以上的读者反馈：

注意：分发时尽量提供校验信息（比如文件大小），读者下载后可以对照，避免拿到半截文件还以为是自己设备的问题。

6. 三格式并行值不值得：我的实际取舍经验

6.1 什么内容适合三格式，什么内容一种就够

三格式并行不是万能公式，它有明确的适用边界。我的判断标准是内容的阅读场景是否分散。《高性价比人生指南》这类指南型内容，读者可能在电脑上通读、在手机上碎片化翻阅、打印出来做笔记，场景分散，三格式就有价值。但如果是一份内部技术文档，读者基本都在电脑上看，做一个HTML或者PDF就够了，硬做EPUB纯属浪费精力。

另一个判断维度是内容是否依赖精细排版。如果内容里有大量图表、信息图、需要精确对齐的对比表，PDF是刚需，EPUB和HTML只能做降级呈现，这时候三格式的意义就打了折扣——读者在EPUB里看到的图表是缩水版，体验不如直接看PDF。反过来，纯文字为主的指南、随笔、教程，流式格式的体验反而更好，三格式并行最划算。

我自己的经验是：内容产品做三格式，工具型文档做一到两种。判断依据就是"读者会不会在不同设备间切换阅读"。会，就三格式；不会，别给自己找活干。

6.2 维护成本的真实账本：改一处要同步三处

三格式并行最容易被低估的是长期维护成本。第一版做完觉得挺顺，等内容要更新的时候，问题就来了：改了Markdown源文件，PDF要重新排版生成、EPUB要重新打包、HTML要重新转换，每一步都可能出新的兼容问题。如果当初没有用单一内容源，而是三份文件各改各的，那基本就是灾难。

所以我在项目一开始就会把构建流程脚本化。写一个简单的shell脚本或者Makefile，一条命令跑完"Markdown → PDF + EPUB + HTML"的全流程，每次更新只改Markdown，然后跑脚本，三份输出自动同步。脚本里把Pandoc参数、CSS路径、输出文件名都固定好，避免每次手动操作引入差异。这个前期投入大概一两个小时，但后面每次更新能省下大量重复劳动，而且保证三份内容绝对一致。

#!/bin/bash # build.sh - 一键生成三格式 set -e pandoc guide.md -o dist/guide.epub --toc --toc-depth=2 \ --css=styles/epub.css --epub-cover-image=assets/cover.jpg \ --metadata title="高性价比人生指南" --metadata lang=zh-CN pandoc guide.md -o dist/guide.html --standalone --toc \ --toc-depth=2 --css=styles/web.css --embed-resources pandoc guide.md -o dist/guide.pdf --pdf-engine=xelatex \ --toc --toc-depth=2 -V CJKmainfont="Noto Sans CJK SC" \ -V geometry:margin=2.5cm echo "构建完成"

这个脚本里set -e保证任何一步失败就停下，不会出现"PDF生成失败但EPUB成功了"却没人发现的情况。PDF那行指定了中文字体，这是中文PDF生成的关键，不指定的话中文可能显示成方块。

6.3 如果重来一次，我会怎么调整

如果让我重新做一遍这个三格式项目，我会在三个地方调整。第一，先定CSS再写内容。我第一版是先写完内容再调样式，结果发现某些排版规则和内容结构冲突，回头改内容很痛苦。正确顺序是先定好标题层级、段落样式、图片规则，再往里填内容。第二，EPUB的兼容性测试提前到制作中期，别等全部做完才在阅读器上测，那时候发现问题返工成本高。第三，HTML版本从一开始就做单文件，别先做多文件版本再合并，合并过程中资源路径很容易出错。

还有一个体会是：别追求三种格式的视觉完全一致。PDF可以精致、EPUB要朴素、HTML要轻快，它们本来就该长得不一样。强行让EPUB模仿PDF的版式，只会得到一个在手机上难读、在电脑上也不好看的怪东西。接受每种格式的"性格"，把各自场景下的体验做到最好，这才是三格式并行的正确心态。读者不会因为你三个版本长得不一样而不满，但一定会因为某个版本在他设备上读不了而放弃。