手机电子书格式选型保姆级教程：5种主流格式硬核对比
版本升级后 API 全变了？别慌。很多做数字内容开发的兄弟，一遇到电子书解析就头大，昨天写的 EPUB 转 PDF 代码，今天换个库版本直接报错。这篇保姆级教程不整虚的，直接拿 手机电子书格式 开刀，把市面上最常见的 5 种格式扒个底朝天。咱们不聊虚的，直接上代码、上对比，帮你彻底搞懂在 2024 年，到底该选哪个格式来搞定你的移动端阅读应用。
01. 五种主流格式的定位与“人设”
在动手写代码之前，你得先搞清楚每种格式是干啥的，这就好比招人，你得知道谁是干粗活的，谁是搞精致的。
1. EPUB (Electronic Publication)
这是目前的绝对主流。由 IDPF 制定，W3C 接手维护。它本质上是 HTML、CSS 和 XML 的压缩包。定位：流式排版，自适应屏幕。
特点：字体可换，样式可改，兼容性好，是各大书城（微信读书、Apple Books、Kindle 部分支持）的首选。
痛点：复杂表格、固定版式书籍（如教材）支持极差，代码量稍大。2. PDF (Portable Document Format)
Adobe 的老大哥，基于 PostScript。定位：固定版式，所见即所得。
特点：打印友好，排版绝对稳定，任何设备打开都一样。
痛点：在手机小屏幕上阅读体验极差（字体太小，缩放模糊），文件体积大，解析逻辑复杂（需要处理字体嵌入、坐标映射）。3. MOBI (Mobipocket)
Amazon 曾经的私有格式，现在逐渐被 AZW3 取代，但存量巨大。定位：早期 Kindle 专用。
特点：压缩率高，解析速度快。
痛点：非标准，生态封闭，除了 Kindle 基本没人用，新项目强烈不建议作为主要输出格式。4. AZW3 / KFX
Amazon 最新的私有格式。定位：下一代 Kindle 标准。
特点：支持更复杂的 CSS，字体嵌入更灵活。
痛点：私有协议，逆向工程难度大，官方 SDK 门槛高。5. TXT / HTML
最底层的文本格式。定位：极简主义，兼容性无敌。
特点：体积小，解析零门槛，任何文本编辑器都能开。
痛点：无样式，无图片支持（HTML 除外），无目录结构，体验粗糙。02. 核心差异深度对比表
为了让你一眼看清区别，我整理了一张核心维度对比表。这张表是你做技术选型时的决策基石，建议截图保存。维度
EPUB 3
PDF
MOBI
AZW3
HTML/TXT标准归属
W3C 国际标准
Adobe 私有标准
Amazon 私有
Amazon 私有
通用标准排版模式
流式 (Reflowable)
固定 (Fixed)
流式
流式
流式手机体验
⭐⭐⭐⭐⭐
⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐解析难度
中等 (XML/HTML)
高 (二进制/CFF)
高 (PDB)
极高 (专有)
低文件体积
小
大
小
小
最小字体支持
支持 CSS 字体
嵌入字体
有限
支持
依赖系统图片支持
优秀
优秀
一般
优秀
一般 (HTML)目录导航
原生支持
依赖书签
原生支持
原生支持
需 JS 实现DRM 加密
支持 (AES)
支持 (Adobe)
支持 (Amazon)
支持
无开源生态
极丰富 (Calibre等)
丰富 (Poppler等)
少
极少
极丰富适用场景
通用阅读、出版
文档、合同、教材
存量 Kindle
新 Kindle
快速原型、笔记关键解读：如果你的产品面向大众阅读，EPUB 是首选，因为它是开放的，用户可以在不同设备间同步。
如果你的产品涉及专业文档、图纸、表单，必须选 PDF，因为版式不能乱。
MOBI 正在死亡，除非你要维护 10 年前的老 Kindle 设备，否则新项目直接忽略它。03. 代码写法对比：如何解析与生成
光说不练假把式。下面我们用 Python 和 JavaScript 分别演示如何处理 EPUB 和 PDF 的核心逻辑。注意，这里为了演示核心差异，代码做了简化，但逻辑是真实的。
3.1 EPUB 解析：基于 XML/HTML 的结构化提取
EPUB 本质是一个 ZIP 包，里面装着 META-INF/container.xml 和一堆 HTML。解析它，就是解压 + 解析 XML。
import zipfile
import xml.etree.ElementTree as ET
from bs4 import BeautifulSoup
import osdef parse_epub_metadata(epub_path):解析 EPUB 文件的元数据 (标题、作者、语言)核心逻辑: 1. 解压 2. 读取 container.xml 3. 读取 OPF 文件 4. 提取 Dublin Core 标签with zipfile.ZipFile(epub_path, 'r') as z:# 第一步: 找到 OPF 文件的位置container_xml = z.read('META-INF/container.xml')root = ET.fromstring(container_xml)# 解析命名空间，避免硬编码ns = {'root': 'urn:oasis:names:tc:opendocument:xmlns:container'}rootfile_path = root.find('.//rootfile', ns).get('full-path')# 第二步: 读取 OPF 文件 (这是 EPUB 的灵魂文件)opf_data = z.read(rootfile_path)opf_root = ET.fromstring(opf_data)# 提取元数据 (Dublin Core)dc_ns = {'dc': 'http://purl.org/dc/elements/1.1/'}title = opf_root.find('.//dc:title', dc_ns).textauthor = opf_root.find('.//dc:creator', dc_ns).textlanguage = opf_root.find('.//dc:language', dc_ns).textprint(f标题: {title})print(f作者: {author})print(f语言: {language})# 第三步: 提取正文内容 (简化版: 只提取第一个章节)# 实际项目中需要遍历 manifest 中的所有 spine 项spine_item = opf_root.find('.//spine/itemref', ns).get('idref')manifest_item = Nonefor item in opf_root.find('.//manifest', ns):if item.get('id') == spine_item:manifest_item = itembreakif manifest_item:content_path = manifest_item.get('href')# 处理路径可能包含子目录的情况if '/' in rootfile_path:base_dir = os.path.dirname(rootfile_path)content_path = os.path.join(base_dir, content_path)html_content = z.read(content_path).decode('utf-8')soup = BeautifulSoup(html_content, 'html.parser')# 提取纯文本text = soup.get_text(separator='\n', strip=True)print(f正文前100字: {text[:100]}...)# 提取图片 (示例)images = soup.find_all('img')for img in images[:2]: # 只取前两张img_src = img.get('src')if img_src:img_full_path = os.path.join(base_dir, img_src)try:img_data = z.read(img_full_path)print(f找到图片: {img_src}, 大小: {len(img_data)} bytes)except KeyError:pass# 测试
# parse_epub_metadata('sample.epub')代码解析：关键点：EPUB 的复杂性在于路径解析。container.xml 指向 OPF，OPF 指向 HTML 和 CSS。路径可能是相对路径，必须正确处理 base_dir。
优势：代码逻辑清晰，基于标准 XML，易调试。3.2 PDF 解析：基于坐标与字体的二进制噩梦
PDF 解析完全不同。它是二进制的，且不保证顺序。文字是散落在页面上的一个个坐标点，字体可能是嵌入的子集，甚至可能是图片里的文字（需要 OCR）。
import fitz # PyMuPDF, 比 PyPDF2 性能更好，功能更强def parse_pdf_structure(pdf_path):解析 PDF 的结构化信息核心逻辑: 1. 加载文档 2. 遍历页面 3. 提取文本块 (Blocks) 4. 分析字体与坐标doc = fitz.open(pdf_path)print(f总页数: {doc.page_count})print(f元数据: {doc.metadata})for page_num in range(min(2, doc.page_count)): # 只解析前两页page = doc.load_page(page_num)# 方法1: 提取纯文本 (丢失布局信息)# text = page.get_text()# 方法2: 提取结构化文本块 (保留布局、字体、坐标)# 'dict' 模式返回嵌套的字典，包含 blocks, lines, spanstext_dict = page.get_text(dict)print(f\n--- 第 {page_num + 1} 页 ---)print(f页面尺寸: {page.rect.width} x {page.rect.height})for block in text_dict['blocks']:if block['type'] == 0: # 0 是文本块, 1 是图片块for line in block['lines']:for span in line['spans']:# 提取关键信息: 文本, 字体, 大小, 坐标text = span['text']font = span['font']size = span['size']bbox = span['bbox'] # [x0, y0, x1, y1]# 过滤空白if text.strip():print(f [{font}, {size:.1f}pt, @({bbox[0]:.1f},{bbox[1]:.1f})] {text[:50]})elif block['type'] == 1: # 图片块print(f [Image] {block['width']}x{block['height']} @ ({block['bbox'][0]:.1f},{block['bbox'][1]:.1f}))doc.close()# 测试
# parse_pdf_structure('sample.pdf')代码解析：关键点：PDF 没有“段落”概念，只有 span（跨度）。你需要通过坐标 (bbox) 和字体大小 来判断哪些 span 属于同一段落。
痛点：如果 PDF 是扫描件（图片），get_text 返回空，你必须调用 page.get_pixmap() 截图，再丢给 OCR 引擎（如 Tesseract）。这就是为什么 PDF 解析代码往往比 EPUB 复杂 3-5 倍。3.3 前端渲染差异：JS 如何展示
在前端，EPUB 通常使用 epub.js，PDF 通常使用 pdf.js。
EPUB.js 渲染逻辑 (流式):
// 依赖: script src=epub.js/script
Rendition = ePub('book.epub');rendition.display(); // 自动根据屏幕宽度重排
rendition.on('relocated', function(location) {// location 包含章节ID、偏移量等console.log(当前位置:, location);
});// 关键点: 没有固定坐标，DOM 是流动的
// 样式由 CSS 控制，用户可以调整字体大小，不影响布局崩溃PDF.js 渲染逻辑 (固定):
// 依赖: script src=pdf.js/script
const pdfjsLib = pdfjsLib;
pdfjsLib.getDocument('book.pdf').promise.then(function(pdf) {pdf.getPage(1).then(function(page) {const viewport = page.getViewport({scale: 1.5}); // 固定缩放const canvas = document.getElementById('canvas');const context = canvas.getContext('2d');canvas.height = viewport.height;canvas.width = viewport.width;page.render({canvasContext: context, viewport: viewport});// 关键点: 渲染到 Canvas 上，是像素级的// 用户缩放 = 重新渲染 Canvas，性能开销大// 文本选择困难，因为文字在 Canvas 像素里，不在 DOM 里});
});差异总结：EPUB 是 DOM-based，文字可选、可复制、可无障碍读取，适配屏幕好。
PDF 是 Canvas-based，文字难选（需要额外叠加透明文本层），缩放卡顿，但版式绝对保真。04. 适用场景与避坑指南
选错格式，等于给产品埋雷。以下是基于真实项目经验的场景建议。
场景一：网文/小说阅读 APP首选：EPUB。
理由：用户会在地铁上、被窝里看，屏幕大小不一。EPUB 的流式排版能保证字体大小适中。
避坑：不要直接显示 HTML，要用 EPUB 阅读器组件。否则遇到长列表、代码块，CSS 溢出会导致页面错乱。
进阶：支持 @font-face 嵌入字体，提升品牌感。场景二：专业教材/技术文档首选：PDF (或 EPUB3 固定版式，但支持率低)。
理由：代码块、公式、图表的位置必须精确。EPUB 流式排版可能会把代码块挤成一行，无法阅读。
避坑：PDF 文件体积大，加载慢。必须实现懒加载，只渲染当前可视区域。
进阶：叠加“文本选择层”（Text Overlay），让用户可以复制代码。这需要后端解析 PDF 生成坐标映射数据。场景三：内部知识库/笔记首选：HTML 或 Markdown (前端渲染)。
理由：开发成本低，交互性强（可加搜索、高亮、链接）。
避坑：不要用 EPUB，因为 EPUB 是“静态出版”概念，不适合频繁更新的“动态内容”。场景四：Kindle 生态集成首选：AZW3 (通过 KFX 转换)。
理由：Amazon 官方要求。
避坑：不要尝试自己写 MOBI/AZW3 生成器。使用 Calibre 命令行工具作为后端服务，将 EPUB 转换为 AZW3。这是行业最佳实践，也是官方源码仓库 (Calibre 在 GitHub) 所支持的稳定方案。05. 选型建议与终极决策树
最后，给你一个简单的决策流程，帮你快速定下技术选型：内容是否需要固定版式？是 (图表、代码、公式) → 选 PDF。
否 (纯文字、小说) → 进入下一步。是否需要支持 Kindle 推送？是 → 选 EPUB 作为源文件，后端用 Calibre 转 AZW3。
否 → 进入下一步。内容更新频率高吗？高 (博客、新闻) → 选 HTML/Markdown，前端渲染。
低 (书籍、课程) → 选 EPUB 3。为什么 EPUB 是大多数情况下的赢家？
因为它是开放标准。你可以查看 IDPF 的官方源码仓库和规范文档，全球开发者都在维护它。这意味着：人才多：招个前端就能改 EPUB 阅读器。
工具全：Calibre, Sigil, Sigil 都有开源支持。
未来稳：W3C 还在持续更新标准，不会像 MOBI 那样突然废弃。最后，一个灵魂拷问：
在移动端阅读场景中，你更倾向于完全保真的固定版式（哪怕手机上看很小），还是牺牲部分排版但保证阅读体验的流式版式？
比如，一本代码书，如果为了手机可读性把代码块拆行，你会接受吗？还是宁可让用户放大缩小？
评论区交流，说出你的选择，以及你踩过的最大的坑。 手机电子书格式选型保姆级教程：5种主流格式硬核对比
手机电子书格式选型保姆级教程：5种主流格式硬核对比
版本升级后 API 全变了？别慌。很多做数字内容开发的兄弟，一遇到电子书解析就头大，昨天写的 EPUB 转 PDF 代码，今天换个库版本直接报错。这篇保姆级教程不整虚的，直接拿 手机电子书格式 开刀，把市面上最常见的 5 种格式扒个底朝天。咱们不聊虚的，直接上代码、上对比，帮你彻底搞懂在 2024 年，到底该选哪个格式来搞定你的移动端阅读应用。
01. 五种主流格式的定位与“人设”
在动手写代码之前，你得先搞清楚每种格式是干啥的，这就好比招人，你得知道谁是干粗活的，谁是搞精致的。
1. EPUB (Electronic Publication)
这是目前的绝对主流。由 IDPF 制定，W3C 接手维护。它本质上是 HTML、CSS 和 XML 的压缩包。定位：流式排版，自适应屏幕。
特点：字体可换，样式可改，兼容性好，是各大书城（微信读书、Apple Books、Kindle 部分支持）的首选。
痛点：复杂表格、固定版式书籍（如教材）支持极差，代码量稍大。2. PDF (Portable Document Format)
Adobe 的老大哥，基于 PostScript。定位：固定版式，所见即所得。
特点：打印友好，排版绝对稳定，任何设备打开都一样。
痛点：在手机小屏幕上阅读体验极差（字体太小，缩放模糊），文件体积大，解析逻辑复杂（需要处理字体嵌入、坐标映射）。3. MOBI (Mobipocket)
Amazon 曾经的私有格式，现在逐渐被 AZW3 取代，但存量巨大。定位：早期 Kindle 专用。
特点：压缩率高，解析速度快。
痛点：非标准，生态封闭，除了 Kindle 基本没人用，新项目强烈不建议作为主要输出格式。4. AZW3 / KFX
Amazon 最新的私有格式。定位：下一代 Kindle 标准。
特点：支持更复杂的 CSS，字体嵌入更灵活。
痛点：私有协议，逆向工程难度大，官方 SDK 门槛高。5. TXT / HTML
最底层的文本格式。定位：极简主义，兼容性无敌。
特点：体积小，解析零门槛，任何文本编辑器都能开。
痛点：无样式，无图片支持（HTML 除外），无目录结构，体验粗糙。02. 核心差异深度对比表
为了让你一眼看清区别，我整理了一张核心维度对比表。这张表是你做技术选型时的决策基石，建议截图保存。维度
EPUB 3
PDF
MOBI
AZW3
HTML/TXT标准归属
W3C 国际标准
Adobe 私有标准
Amazon 私有
Amazon 私有
通用标准排版模式
流式 (Reflowable)
固定 (Fixed)
流式
流式
流式手机体验
⭐⭐⭐⭐⭐
⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐⭐
⭐⭐⭐解析难度
中等 (XML/HTML)
高 (二进制/CFF)
高 (PDB)
极高 (专有)
低文件体积
小
大
小
小
最小字体支持
支持 CSS 字体
嵌入字体
有限
支持
依赖系统图片支持
优秀
优秀
一般
优秀
一般 (HTML)目录导航
原生支持
依赖书签
原生支持
原生支持
需 JS 实现DRM 加密
支持 (AES)
支持 (Adobe)
支持 (Amazon)
支持
无开源生态
极丰富 (Calibre等)
丰富 (Poppler等)
少
极少
极丰富适用场景
通用阅读、出版
文档、合同、教材
存量 Kindle
新 Kindle
快速原型、笔记关键解读：如果你的产品面向大众阅读，EPUB 是首选，因为它是开放的，用户可以在不同设备间同步。
如果你的产品涉及专业文档、图纸、表单，必须选 PDF，因为版式不能乱。
MOBI 正在死亡，除非你要维护 10 年前的老 Kindle 设备，否则新项目直接忽略它。03. 代码写法对比：如何解析与生成
光说不练假把式。下面我们用 Python 和 JavaScript 分别演示如何处理 EPUB 和 PDF 的核心逻辑。注意，这里为了演示核心差异，代码做了简化，但逻辑是真实的。
3.1 EPUB 解析：基于 XML/HTML 的结构化提取
EPUB 本质是一个 ZIP 包，里面装着 META-INF/container.xml 和一堆 HTML。解析它，就是解压 + 解析 XML。
import zipfile
import xml.etree.ElementTree as ET
from bs4 import BeautifulSoup
import osdef parse_epub_metadata(epub_path):解析 EPUB 文件的元数据 (标题、作者、语言)核心逻辑: 1. 解压 2. 读取 container.xml 3. 读取 OPF 文件 4. 提取 Dublin Core 标签with zipfile.ZipFile(epub_path, 'r') as z:# 第一步: 找到 OPF 文件的位置container_xml = z.read('META-INF/container.xml')root = ET.fromstring(container_xml)# 解析命名空间，避免硬编码ns = {'root': 'urn:oasis:names:tc:opendocument:xmlns:container'}rootfile_path = root.find('.//rootfile', ns).get('full-path')# 第二步: 读取 OPF 文件 (这是 EPUB 的灵魂文件)opf_data = z.read(rootfile_path)opf_root = ET.fromstring(opf_data)# 提取元数据 (Dublin Core)dc_ns = {'dc': 'http://purl.org/dc/elements/1.1/'}title = opf_root.find('.//dc:title', dc_ns).textauthor = opf_root.find('.//dc:creator', dc_ns).textlanguage = opf_root.find('.//dc:language', dc_ns).textprint(f标题: {title})print(f作者: {author})print(f语言: {language})# 第三步: 提取正文内容 (简化版: 只提取第一个章节)# 实际项目中需要遍历 manifest 中的所有 spine 项spine_item = opf_root.find('.//spine/itemref', ns).get('idref')manifest_item = Nonefor item in opf_root.find('.//manifest', ns):if item.get('id') == spine_item:manifest_item = itembreakif manifest_item:content_path = manifest_item.get('href')# 处理路径可能包含子目录的情况if '/' in rootfile_path:base_dir = os.path.dirname(rootfile_path)content_path = os.path.join(base_dir, content_path)html_content = z.read(content_path).decode('utf-8')soup = BeautifulSoup(html_content, 'html.parser')# 提取纯文本text = soup.get_text(separator='\n', strip=True)print(f正文前100字: {text[:100]}...)# 提取图片 (示例)images = soup.find_all('img')for img in images[:2]: # 只取前两张img_src = img.get('src')if img_src:img_full_path = os.path.join(base_dir, img_src)try:img_data = z.read(img_full_path)print(f找到图片: {img_src}, 大小: {len(img_data)} bytes)except KeyError:pass# 测试
# parse_epub_metadata('sample.epub')代码解析：关键点：EPUB 的复杂性在于路径解析。container.xml 指向 OPF，OPF 指向 HTML 和 CSS。路径可能是相对路径，必须正确处理 base_dir。
优势：代码逻辑清晰，基于标准 XML，易调试。3.2 PDF 解析：基于坐标与字体的二进制噩梦
PDF 解析完全不同。它是二进制的，且不保证顺序。文字是散落在页面上的一个个坐标点，字体可能是嵌入的子集，甚至可能是图片里的文字（需要 OCR）。
import fitz # PyMuPDF, 比 PyPDF2 性能更好，功能更强def parse_pdf_structure(pdf_path):解析 PDF 的结构化信息核心逻辑: 1. 加载文档 2. 遍历页面 3. 提取文本块 (Blocks) 4. 分析字体与坐标doc = fitz.open(pdf_path)print(f总页数: {doc.page_count})print(f元数据: {doc.metadata})for page_num in range(min(2, doc.page_count)): # 只解析前两页page = doc.load_page(page_num)# 方法1: 提取纯文本 (丢失布局信息)# text = page.get_text()# 方法2: 提取结构化文本块 (保留布局、字体、坐标)# 'dict' 模式返回嵌套的字典，包含 blocks, lines, spanstext_dict = page.get_text(dict)print(f\n--- 第 {page_num + 1} 页 ---)print(f页面尺寸: {page.rect.width} x {page.rect.height})for block in text_dict['blocks']:if block['type'] == 0: # 0 是文本块, 1 是图片块for line in block['lines']:for span in line['spans']:# 提取关键信息: 文本, 字体, 大小, 坐标text = span['text']font = span['font']size = span['size']bbox = span['bbox'] # [x0, y0, x1, y1]# 过滤空白if text.strip():print(f [{font}, {size:.1f}pt, @({bbox[0]:.1f},{bbox[1]:.1f})] {text[:50]})elif block['type'] == 1: # 图片块print(f [Image] {block['width']}x{block['height']} @ ({block['bbox'][0]:.1f},{block['bbox'][1]:.1f}))doc.close()# 测试
# parse_pdf_structure('sample.pdf')代码解析：关键点：PDF 没有“段落”概念，只有 span（跨度）。你需要通过坐标 (bbox) 和字体大小 来判断哪些 span 属于同一段落。
痛点：如果 PDF 是扫描件（图片），get_text 返回空，你必须调用 page.get_pixmap() 截图，再丢给 OCR 引擎（如 Tesseract）。这就是为什么 PDF 解析代码往往比 EPUB 复杂 3-5 倍。3.3 前端渲染差异：JS 如何展示
在前端，EPUB 通常使用 epub.js，PDF 通常使用 pdf.js。
EPUB.js 渲染逻辑 (流式):
// 依赖: script src=epub.js/script
Rendition = ePub('book.epub');rendition.display(); // 自动根据屏幕宽度重排
rendition.on('relocated', function(location) {// location 包含章节ID、偏移量等console.log(当前位置:, location);
});// 关键点: 没有固定坐标，DOM 是流动的
// 样式由 CSS 控制，用户可以调整字体大小，不影响布局崩溃PDF.js 渲染逻辑 (固定):
// 依赖: script src=pdf.js/script
const pdfjsLib = pdfjsLib;
pdfjsLib.getDocument('book.pdf').promise.then(function(pdf) {pdf.getPage(1).then(function(page) {const viewport = page.getViewport({scale: 1.5}); // 固定缩放const canvas = document.getElementById('canvas');const context = canvas.getContext('2d');canvas.height = viewport.height;canvas.width = viewport.width;page.render({canvasContext: context, viewport: viewport});// 关键点: 渲染到 Canvas 上，是像素级的// 用户缩放 = 重新渲染 Canvas，性能开销大// 文本选择困难，因为文字在 Canvas 像素里，不在 DOM 里});
});差异总结：EPUB 是 DOM-based，文字可选、可复制、可无障碍读取，适配屏幕好。
PDF 是 Canvas-based，文字难选（需要额外叠加透明文本层），缩放卡顿，但版式绝对保真。04. 适用场景与避坑指南
选错格式，等于给产品埋雷。以下是基于真实项目经验的场景建议。
场景一：网文/小说阅读 APP首选：EPUB。
理由：用户会在地铁上、被窝里看，屏幕大小不一。EPUB 的流式排版能保证字体大小适中。
避坑：不要直接显示 HTML，要用 EPUB 阅读器组件。否则遇到长列表、代码块，CSS 溢出会导致页面错乱。
进阶：支持 @font-face 嵌入字体，提升品牌感。场景二：专业教材/技术文档首选：PDF (或 EPUB3 固定版式，但支持率低)。
理由：代码块、公式、图表的位置必须精确。EPUB 流式排版可能会把代码块挤成一行，无法阅读。
避坑：PDF 文件体积大，加载慢。必须实现懒加载，只渲染当前可视区域。
进阶：叠加“文本选择层”（Text Overlay），让用户可以复制代码。这需要后端解析 PDF 生成坐标映射数据。场景三：内部知识库/笔记首选：HTML 或 Markdown (前端渲染)。
理由：开发成本低，交互性强（可加搜索、高亮、链接）。
避坑：不要用 EPUB，因为 EPUB 是“静态出版”概念，不适合频繁更新的“动态内容”。场景四：Kindle 生态集成首选：AZW3 (通过 KFX 转换)。
理由：Amazon 官方要求。
避坑：不要尝试自己写 MOBI/AZW3 生成器。使用 Calibre 命令行工具作为后端服务，将 EPUB 转换为 AZW3。这是行业最佳实践，也是官方源码仓库 (Calibre 在 GitHub) 所支持的稳定方案。05. 选型建议与终极决策树
最后，给你一个简单的决策流程，帮你快速定下技术选型：内容是否需要固定版式？是 (图表、代码、公式) → 选 PDF。
否 (纯文字、小说) → 进入下一步。是否需要支持 Kindle 推送？是 → 选 EPUB 作为源文件，后端用 Calibre 转 AZW3。
否 → 进入下一步。内容更新频率高吗？高 (博客、新闻) → 选 HTML/Markdown，前端渲染。
低 (书籍、课程) → 选 EPUB 3。为什么 EPUB 是大多数情况下的赢家？
因为它是开放标准。你可以查看 IDPF 的官方源码仓库和规范文档，全球开发者都在维护它。这意味着：人才多：招个前端就能改 EPUB 阅读器。
工具全：Calibre, Sigil, Sigil 都有开源支持。
未来稳：W3C 还在持续更新标准，不会像 MOBI 那样突然废弃。最后，一个灵魂拷问：
在移动端阅读场景中，你更倾向于完全保真的固定版式（哪怕手机上看很小），还是牺牲部分排版但保证阅读体验的流式版式？
比如，一本代码书，如果为了手机可读性把代码块拆行，你会接受吗？还是宁可让用户放大缩小？
评论区交流，说出你的选择，以及你踩过的最大的坑。