做 Kindle 推送这件事，说难不难，说简单也容易翻车。第一次折腾的人多半会遇到这几种情况：邮件发出去了石沉大海，设备上什么也没收到；好不容易收到一本，打开发现满屏乱码，或者封面变成一张灰底占位图；再或者是想把一篇还不错的网页文章推到 Kindle 上，结果导出来一堆导航栏、广告位和评论区，正文只剩三行。我自己折腾这套东西有些年头了，从最早的邮箱推送、到后来官方出的网页上传入口、再到自己写脚本把网页转成电子书，中间踩过的坑基本都踩了一遍。这篇就把 Kindle 推送和个人文档这条链路的完整逻辑、操作步骤、参数取舍，以及推送网页到 Kindle 的几条不同路线全部摊开讲清楚。内容偏向实操，适合刚入手设备的新人，也适合已经开始用 Kindle 看长文、但一直被排版和格式折磨的老用户。每一个步骤我都会说清楚“为什么这么做”，参数能算的就把算法写出来，这样你换设备、换软件也不会慌。

1. 先把 Kindle 推送的底层逻辑搞清楚

1.1 Kindle 推送不是“传文件”，而是“投稿入库”

很多人对 Kindle 推送有一个误解，以为它跟蓝牙传文件、U 盘拷文件是一回事，实际上完全不是。Kindle 推送的官方名称叫个人文档服务，它的流程是三段式的：你通过某个入口把文件交上去，服务端先把文件收进你的云端个人文档库，然后你的设备和 Kindle App 再从云端把这份文档同步下载下来。也就是说，文件先“入库”，再“分发”，你手上那台设备只是一个下载终端。

理解这一点之后，很多现象就顺理成章了。比如为什么邮件发出去十分钟了设备还没反应——因为中间有入库和排队同步的过程，慢的时候十几分钟很正常；为什么同一本书推两次会出现两本——因为是两次独立的入库动作，云端存了两份文件；为什么手机上删了 Kindle App 里的文档，设备上还有——因为删的是本地缓存，云端那份还在。搞清楚这个三层结构，后面所有排查都能按下图思路走：先确认“有没有入库”，再确认“有没有同步到设备”。

还有一个容易忽略的点：个人文档和从商店买的书，在云端是分开管理的，删除个人文档不会影响你买的书，反过来也一样。所以不用担心手滑。

1.2 三条正规通道，各自的适用边界

目前把文件送进 Kindle 云端，常见的通道有三类，理解它们的差异比死记步骤更重要。

第一类是邮件附件推送。你用自己的邮箱，把文件作为附件发到 Kindle 的专属接收邮箱，服务端校验发件人是否在白名单里，通过就入库。优点是通用性最强，任何能发邮件的设备都能用，手机上、电脑上、甚至脚本里都能发；缺点是有附件体积上限，而且不支持压缩包、不支持批量打包，一次一本。

第二类是网页上传或客户端上传。官方的“发送至 Kindle”网页入口和桌面客户端，本质是把文件直接上传，绕过了邮件系统的限制，所以单文件体积上限高得多，格式支持也更全。优点是快、省事、能传大文件；缺点是需要登录账号，在别人的电脑上不太方便。

第三类是浏览器扩展和第三方工具。这类工具做的事是“先帮你把内容加工成电子书，再调用前两种通道上传”。它解决的不是传输问题，而是内容形态转换问题——把网页、RSS、稍后读列表变成适合墨水屏阅读的 EPUB 或 PDF。

至于 USB 数据线拷贝，严格说不算推送：文件只在本地，不进云端，多设备不同步，阅读进度、标注、生词本也不会跨设备打通。偶尔应急可以，长期用不推荐。

1.3 三通道横向对比与选型建议

选型的逻辑其实很简单：文件小、要自动化，走邮件；文件大、要省事，走网页上传；内容在网页上，走扩展或脚本。别指望一条通道解决所有场景，混着用才是常态。我自己是日常网页长文走扩展，扫描版 PDF 走网页上传，定期同步的资料用脚本走邮件，三套并行互不干扰。

2. 前期准备：账号、白名单与同步开关

2.1 找到你的专属接收邮箱

每个 Kindle 账号都有一个专属的个人文档接收邮箱，格式一般是“账号名@某后缀”，后缀跟你注册时选的站点绑定。找它的路径有两处：一是在设备的设置里，进入“你的账户”相关的信息页，能看到“发送至 Kindle 邮箱地址”；二是在网页端的“管理你的内容与设备”里，个人文档设置区域同样能看到。

这个地址建议直接存到通讯录里，命名成“Kindle 推送”，以后发文件不用每次翻。要注意的是，这个地址不能拿来收普通邮件，它只处理附件推送，正文写什么都没有意义，甚至写了长篇大论也不算内容，Kindle 只认附件。我第一次用的时候在正文里写了一大段笔记，结果推过去打开只有排版干净的标题页，正文空空，还以为出 bug 了。

另外，如果你有多个设备绑在同一个账号下，接收邮箱是共享的，也就是说推送一次，所有设备都能看到同一个文档，这一点很方便。

2.2 已批准发件人列表：最容易踩的坑

这一条必须单独拎出来讲，因为九成“推送失败”都栽在这里。出于防垃圾邮件的考虑，Kindle 的个人文档服务默认只接收来自“已批准发件人列表”里的邮箱发来的内容，不在列表里的发件人，邮件会被静默丢弃——注意，是静默，不会有退信，也不会有任何提示，你只会觉得奇怪，为什么发了没反应。

解决方式是在个人文档设置页面里，找到“已批准的个人文档电子邮件列表”，把你常用的发件邮箱加进去。这里有个细节：添加之后需要点确认链接，一般会往你刚添加的邮箱发一封验证邮件，点完才算生效。很多人加完就关页面了，没点验证，等于白加。

注意：白名单是按“完整邮箱地址”匹配的，别名、转发地址、企业邮的二级域名都算不同地址。如果你用邮件客户端设置了转发，实际发件人可能和你以为的不一样，务必以“收件人看到的发件地址”为准。

我吃过一次亏：用一个新注册的邮箱发文件，忘了加白名单，连续发了三天，每天发一次，最后在云端看到零记录，白白浪费了时间。从那以后我养成了一个习惯——换发件邮箱的第一件事就是先加白名单，再发一封测试邮件跑通链路，确认无误再批量操作。

2.3 设备端和 App 端要打开的两个开关

光把文件送上云还不够，设备侧也得愿意下。Kindle 设备里有两个相关设置值得检查：一个是个人文档的接收开关，确保没有被关掉；另一个是 Wi-Fi 下的自动同步，如果关掉了，设备不联网就不会主动拉取。

手机和平板上的 Kindle App 也有类似设置，一般在设置里的“个人文档”或者“同步”相关选项中。我遇到过一种情况：设备一直收不到，折腾半天发现是 App 端把个人文档下载关掉了，只同步商店购买的书。

还有一个隐蔽问题——账号错配。有些人的设备登录的是一个账号，推送用的邮箱是另一个账号的接收地址，两边对不上，自然收不到。检查方法很简单：在设备上打开“管理你的内容”，看云端列表里有没有你刚推的那份文件。有，就是同步问题；没有，就是推送环节的问题。这一步能把排查范围直接砍掉一半。

2.4 别忽略这些硬性限制

几条限制最好提前知道，省得撞墙：

• 附件体积：邮件通道有单封邮件附件总大小的上限，通常在 25MB 这个量级，具体数值各站点页面会写，以你看到的为准。超过就换网页上传。
• 附件数量：一封邮件塞多个附件是支持的，但有数量上限，而且不支持压缩包，zip、rar 一律不认，必须先解压再传。
• 格式限制：不是所有电子书格式都收。EPUB、PDF、DOCX、DOC、TXT、RTF、HTML、以及常见图片格式（JPG、PNG、GIF、BMP）是常规支持的。老的 MOBI、AZW 系列在近年已经不再作为推荐格式，新内容优先用 EPUB。
• 频率：短时间内高频推送可能被限流，批量场景建议加个间隔，别一口气连发几十封。

这些数字会随服务调整，我不建议你死记，但建议你在批量操作前先去设置页面扫一眼当前说明，三十秒的事，能省掉一小时的困惑。

3. 邮件推送实操：从本地文件到书架

3.1 格式怎么选：EPUB 优先，PDF 有条件的用

格式选择直接决定阅读体验，这里没有什么“都行”，差别很大。

EPUB 是首选。它是流式排版，字体、字号、行距、页边距都能在设备上实时调整，图片会跟着重排，长文阅读体验最好。缺点是它对排版的控制权交给了阅读器，如果你需要精确还原版式（比如诗歌、代码块对齐、复杂表格），EPUB 会显得松散。

PDF 适合固定版式的内容。扫描件、带公式的论文、图文混排的画册、需要精确还原的报表，PDF 是唯一选择。但 PDF 在 Kindle 上的体验是双刃剑：小屏幕看 A4 版面必然要缩放，缩放之后要么字小如蚁，要么需要来回平移。所以我的经验是，PDF 推送前先做页面重排，把页面尺寸裁到接近 6 英寸屏幕的比例，正文重新排版，宁可多花五分钟，也别让自己看半小时就想放弃。

DOCX 和 TXT属于应急选项。DOCX 支持还行，但复杂样式会丢；TXT 最稳，但完全没有排版，连章节都分不出来，只适合纯文字草稿。

老的 MOBI、AZW3要特别说一句：AZW3 是 Kindle 的自有格式，但它主要是给本地拷贝和商店内容用的，走个人文档推送这条路并不友好。手里有 MOBI 或 AZW3 的话，最省事的做法是先用转换工具转成 EPUB 再推。

3.2 一次完整的邮件推送演示

流程本身很短，但每一步都有讲究：

1. 准备文件。确认格式是 EPUB 或 PDF，文件名建议用“书名 - 作者”这种结构，因为很多情况下文件名会直接影响书架上显示的标题。
2. 新建邮件。收件人填你的 Kindle 接收邮箱；主题可以留空，也可以写书名，部分场景下主题会被当作标题使用；正文留空即可，写内容没用。
3. 添加附件。单个文件直接拖进去；多个文件注意总体积别超限。
4. 发送。用白名单里的邮箱发。
5. 等待入库。通常几分钟到十几分钟。期间可以在网页端“管理你的内容”里刷新看有没有出现。
6. 设备同步。设备连 Wi-Fi 后会自动拉取，也可以在设置里手动点一次同步。

如果推到一半想改，比如发现文件名写错了，直接重推一份新的就行，旧的那份在云端手动删掉，别留着占地方。

3.3 用脚本批量推送：一次配置，长期省事

手头资料多的时候，一封封发邮件很折磨人。这时候用脚本走 SMTP 最省事。下面这段是核心逻辑，用 Python 写的，作用是把指定目录下的电子书逐个发到 Kindle 邮箱。

import os import smtplib from email.message import EmailMessage from email.utils import formataddr SMTP_HOST = "smtp.example.com" # 换成你邮箱服务商的 SMTP 地址 SMTP_PORT = 465 # SSL 端口通常 465，STARTTLS 通常 587 SENDER = "your_mail@example.com" # 必须在已批准发件人列表里 AUTH_CODE = os.environ["MAIL_AUTH_CODE"] # 授权码走环境变量，别硬编码 KINDLE_MAIL = "your_name@kindle.com" # 你的 Kindle 接收邮箱 BOOK_DIR = "./books" MAX_SIZE_MB = 20 # 保守一点，留出邮件编码膨胀的余量 def send_one(path): size_mb = os.path.getsize(path) / 1024 / 1024 if size_mb > MAX_SIZE_MB: print(f"跳过（体积 {size_mb:.1f}MB 超限）：{path}") return msg = EmailMessage() msg["From"] = formataddr(("Push Bot", SENDER)) msg["To"] = KINDLE_MAIL msg["Subject"] = os.path.splitext(os.path.basename(path))[0] with open(path, "rb") as f: data = f.read() msg.add_attachment( data, maintype="application", subtype="epub+zip" if path.lower().endswith(".epub") else "octet-stream", filename=os.path.basename(path), ) with smtplib.SMTP_SSL(SMTP_HOST, SMTP_PORT) as s: s.login(SENDER, AUTH_CODE) s.send_message(msg) print(f"已发送：{path}") for name in sorted(os.listdir(BOOK_DIR)): if name.lower().endswith((".epub", ".pdf")): send_one(os.path.join(BOOK_DIR, name))

几个实操要点。第一，授权码走环境变量，不要写在代码里，脚本一旦分享出去就是事故。第二，体积上限留余量，邮件编码会让实际传输体积比原文件大三分之一左右，所以我把阈值压到 20MB，宁可走网页上传也别撞上限。第三，加发送间隔，批量发的时候在循环里加个time.sleep(5)，避免被当成异常流量。第四，先发一封测试，确认链路通了再跑全量。

我自己是用这套脚本做定期同步的：一个目录扔新书，跑一次脚本，全部入库。跑了大半年，除了偶尔因为网络抖动失败一两次（重跑即可），基本没出过问题。

3.4 封面、目录和字体的三个隐形坑

封面丢失是最常见的抱怨。EPUB 的封面是写在元数据里的，有些制作粗糙的文件压根没嵌封面，推过去书架上一片灰。解决办法是用电子书管理工具打开文件，手动指定封面图，重新保存一次。如果只是自己看，其实也不影响阅读，但书架上一排灰块确实难受。

目录缺失的根源在于文件内部没有生成导航结构。EPUB 的目录靠内部导航文件支撑，PDF 的目录靠书签。转格式的时候如果工具没勾选“生成目录”，推过去就只能靠翻页找位置。转换时记得把这一项打开。

字体问题主要出现在 PDF 上。PDF 里嵌了什么字体就显示什么字体，如果嵌了一个特别细的字体，在墨水屏上看着会发虚。我的处理方式是在重排的时候统一换成笔画清晰的常见字体，字号不小于 11pt，行距 1.5 倍左右，这个组合在小屏上最耐看。

4. 推送网页到 Kindle 的四条路线

4.1 路线一：浏览器扩展一键转换，最省事

这是绝大多数人第一次成功把网页推到 Kindle 上用的方法。原理并不神秘：扩展在浏览器里读取当前页面，用正文提取算法把导航栏、侧边栏、广告、评论区、相关推荐全部剥离，只留下文章主体，然后重新排版生成一份 EPUB 或 PDF，再调用官方上传接口送进你的云端。

操作上通常是三步：装扩展、在页面点一下按钮、在弹出的面板里确认标题和作者。整个过程十几秒。它的优势是几乎零配置，缺点是可控性差——正文提取算法遇到特殊页面结构会失手，比如正文被拆在多个分页里、图片是懒加载的、代码块用特殊标签渲染的，导出来可能缺内容。

用这类工具时我有个固定习惯：先看预览再发送。多数扩展都提供预览，翻两页看看正文有没有缺、图片在不在、代码块有没有被吃。花十秒检查，能避免推过去才发现是残篇。

还有一个细节值得说：分页文章的合并。很多长文会被拆成“第 1 页 / 第 2 页 / 第 3 页”，扩展通常只抓当前页。遇到这种，要么找“阅读全文”或“单页模式”的入口，要么手动把各页内容拼起来再转，不然推过去就是断章。

4.2 路线二：打印成 PDF 再上传，最通用

浏览器自带的打印功能被严重低估了。按快捷键调出打印面板，目标选“另存为 PDF”，你就会得到一份干净的、去掉所有交互元素的静态文档。它的好处是完全可控：哪些元素要、哪些不要，用打印样式就能控制；页面尺寸、页边距、缩放比例全都能调。

页面尺寸这一步是关键。默认的 A4 比例放到 6 英寸屏上，字会小得难受。我的做法是在打印面板里把纸张尺寸调成接近 3:4 或 4:3 的比例（比如自定义成 15cm × 20cm 这种量级），然后调整缩放百分比，让正文一行大约 30 到 40 个汉字。这个行宽在墨水屏上是舒适区，再宽眼睛要来回扫，太窄又频繁换行。

打印前还有一个操作强烈推荐：用阅读模式。主流浏览器都有阅读视图，开启之后页面会自动去噪，只剩正文和配图，这时候再打印，出来的 PDF 干净得像专门排过版。这一步能把后面的手工清理工作省掉九成。

PDF 出来之后走网页上传通道，体积大的话也没关系，比邮件通道宽松得多。唯一要注意的是图片质量，打印成 PDF 时图片会被重新采样，如果原文有高清图表，建议在打印设置里把质量调到最高，否则放大看会糊。

4.3 路线三：稍后读服务加定时投递，最省心

如果你每天要读的网页不止一两篇，逐篇推送就太累了。这时候用“稍后读”的思路更合适：平时在浏览器里点一下收藏，服务端把正文抓下来存好，然后按你设定的时间（比如每天早上六点）打包成一本合辑，自动发到 Kindle 邮箱。你早上拿起设备，昨天的收藏已经排好队了。

这条链路的关键是自动投递。选择工具时要确认它支持把收藏内容定时发送到 Kindle 接收邮箱，很多稍后读服务都有这个功能，通常在设置里的“发送到设备”或者“每日摘要”这一类选项里。配置时要注意三点：投递频率别太高（每天一次足够）、单次篇数设个上限（我一般设 10 到 15 篇，太多会变成负担）、以及别忘了把服务的发件地址加进白名单。

这条路线的体验是最“无感”的，但也有代价：你对排版的掌控力最弱，抓取质量取决于服务商的算法。遇到重要文章，我还是会走路线一或路线二，确保内容完整。

4.4 路线四：自建抓取脚本，可控性最高

对内容和格式都有要求的人，最后多半会走到这一步：自己抓、自己转、自己发。好处是所有环节都在手里，坏处是要写点代码。核心链路是三段：抓正文、生成 EPUB、走邮件或上传。

抓正文推荐用成熟的可读性提取库，比如 Python 生态里的readability-lxml，它的算法和浏览器阅读模式同源，去噪效果稳定。生成 EPUB 用ebooklib，几行代码就能拼出一本带目录、带样式的电子书。

from ebooklib import epub import ebooklib from readability import Document import requests def html_to_epub(url, out_path): resp = requests.get(url, timeout=20, headers={ "User-Agent": "Mozilla/5.0 (compatible; KindlePush/1.0)" }) resp.encoding = resp.apparent_encoding doc = Document(resp.text) title = doc.short_title() or "未命名文章" content = doc.summary() # 已去噪的正文 HTML 片段 book = epub.EpubBook() book.set_identifier(url) book.set_title(title) book.set_language("zh") book.add_author("Web Archive") # 统一正文样式：字号、行距、段距、图片宽度 style = """ body { font-size: 1em; line-height: 1.6; margin: 0 0.6em; } p { margin: 0 0 0.8em 0; text-indent: 2em; } img { max-width: 100%; height: auto; } pre { white-space: pre-wrap; word-wrap: break-word; font-size: 0.85em; } """ css = epub.EpubItem(uid="style", file_name="style/main.css", media_type="text/css", content=style) chapter = epub.EpubHtml(title=title, file_name="chap_01.xhtml", lang="zh") chapter.content = f"<h2>{title}</h2>{content}" chapter.add_item(css) book.add_item(css) book.add_item(chapter) book.toc = (chapter,) book.add_item(epub.EpubNcx()) book.add_item(epub.EpubNav()) book.spine = ["nav", chapter] epub.write_epub(out_path, book, {}) print(f"已生成：{out_path}") html_to_epub("https://example.com/some-article", "./out/article.epub")

这段代码的注释里其实藏着几个经验值。line-height: 1.6是我在墨水屏上试下来最舒服的行距，1.4 偏挤，1.8 又太散。text-indent: 2em是中文段落的首行缩进习惯，不加会像代码文档。pre标签里的pre-wrap是为了防止长代码行被截断——这个坑我踩过，推过去之后代码右边整段消失，还以为抓取失败，其实是pre默认不换行。

如果要抓 RSS，电子书管理工具自带的“获取新闻”功能其实已经很好用了，配置好订阅源，它能按计划抓取、合并成一本、自动发送，不需要写代码。我一般用它处理固定的几个技术博客，用脚本处理零散的单篇长文，两条腿走路。

4.5 四条路线怎么选

我的实际组合是：随手看到的用扩展，重要的长文用打印，每天固定的几个源用 RSS 自动抓，偶尔需要精排的用脚本。四套并行，各管一段，不追求“一招通吃”。

5. 排版调优：让推送过来的内容真的能读

5.1 去噪是第一步，也是最关键的一步

网页和电子书最大的差别不是内容，而是噪音密度。一篇文章在浏览器里读着没问题，是因为视觉焦点被排版引导了；但推送到 Kindle 之后，所有元素平铺直叙，导航栏、分享按钮、作者简介、相关推荐、评论区全挤在一起，正文被埋在里面，翻三页还没进主题，阅读欲望直接归零。

所以不管你走哪条路线，去噪都是必须做的。手段有三个层次：最省事的是用阅读模式或正文提取算法，让工具替你剥；中等的是打印前手动隐藏干扰元素，用浏览器的元素选择器把侧栏、浮层、推荐位设为不显示；最彻底的是自建脚本，在生成 EPUB 之前用选择器把非正文节点全部剔除。

判断去噪是否成功有个简单标准：推送后的文档，第一页应该直接是标题加正文开头。如果第一页还是站点 logo、栏目导航、作者头像，说明去噪没做到位，回去再处理一次。

5.2 字号、行距、页边距的具体数值

这三个参数决定了阅读时的眼睛负担，值得认真调。我在 6 英寸屏上试过多轮，结论是：

• 字号：正文基准 1em（在设备上通常对应中等字号），不要小于 0.9em，否则在弱光下吃力。
• 行距：1.5 到 1.7 倍之间最舒服，我固定用 1.6。低于 1.4 会显得密不透风，高于 1.8 会导致频繁翻页。
• 页边距：左右各 0.5 到 0.8em 比较合适。太窄贴边，拇指容易挡住；太宽则浪费屏宽。
• 段距：段与段之间留 0.6 到 0.8em，配合首行缩进，段落界限清晰又不松散。
• 图片宽度：一律限制在 100% 屏宽以内，高度自适应。超过宽度的图会被裁切或缩放失真。

这些值不是玄学，你可以自己算一下：6 英寸屏的可用宽度大约是 90 毫米，一行 30 到 40 个汉字对应每个字 2.2 到 3 毫米，这个尺寸在正常阅读距离下是舒适区。所以调参的目标就是让一行的字数落在这个区间，字号和边距都是围绕这个目标服务的。

5.3 图片和体积的平衡

图片是体积的主要来源，也是同步慢的主要原因。一张未压缩的手机照片动辄三五 MB，塞十几张进去，EPUB 就变成几十 MB，上传慢、下载慢、翻页也卡。

处理原则很简单：屏幕只有 6 英寸，像素密度再高也用不上原图。把图片宽度压到 800 到 1200 像素，格式用 JPEG，质量 80% 左右，视觉上几乎看不出差别，体积能降一个数量级。如果是黑白文档里的插图，直接转灰度，体积还能再降一半。至于装饰性的图标、分隔线、背景图，全部删掉，它们在墨水屏上除了占体积没有任何价值。

5.4 目录结构：长文必须有

单篇短文无所谓，但超过一万字的内容，没有目录会非常痛苦。EPUB 的目录依赖内部导航文件，生成时要确保写入了导航结构，并且章节标题用了正确的标题标签（h1 到 h3），工具才能自动识别。

如果是自己拼合的多篇文章，建议按来源分组，每篇一个章节，章节标题用文章标题。这样在设备上打开目录就能直接跳转，比一页页翻高效得多。我在处理系列文章时还会在开头加一页简单的索引，列出所有篇目和大致位置，虽然目录已经能跳，但有个总览页心里更有底。

6. 常见问题排查实录

6.1 收不到推送？按这个顺序查

排查最忌讳东试一下西试一下，按链路顺序走，五分钟能定位八成问题。

第一步，查云端有没有入库。打开“管理你的内容”，看个人文档列表里有没有刚推的那份。有，说明推送成功，问题在同步；没有，说明根本没进来，问题在推送环节。

第二步，推送环节查三件事。发件邮箱在不在白名单里、白名单有没有完成验证、附件体积和格式是否合规。这三条覆盖了绝大多数失败原因。特别注意白名单验证邮件可能被扔进垃圾箱，加完记得去翻一下。

第三步，同步环节查两件事。设备是否联网、账号是否一致。设备上打开内容管理，如果能看见云端那份文档，只是没下载，手动点一下就能拉下来。

第四步，查延迟。服务端排队是常态，尤其是晚上高峰，等二十分钟不算异常。别急着重发，重发只会多一份重复文件。

6.2 打开了但是乱码、空白、缺图

乱码基本都出在 TXT 上。原因是编码不匹配，很多老文件是 GBK 编码，服务端按 UTF-8 解析就成乱码。解决办法是用文本编辑器另存为 UTF-8，再推一次。EPUB 乱码比较少见，如果出现，多半是文件本身的字符集声明写错了。

空白页常见于两类情况。一类是 PDF 加密或加了权限保护，服务端能收但不能正常渲染；另一类是扫描件没有文字层，某些转换流程会把它当成空页。前者需要先解除保护（自己有权处理的文件），后者建议直接传 PDF 原件而不是转格式。

缺图多数是路径问题。EPUB 里的图片用的是相对路径，如果生成工具把图片放在了一个目录、正文引用了另一个路径，图片就加载不出来。自建脚本时尤其要注意，图片资源必须作为独立条目加进书里，不能只在 HTML 里写个外链——Kindle 设备离线时外链是加载不了的。

6.3 重复文件与云端清理

同一份内容推两次，云端就有两份，书架上也显示两个条目。清理入口在“管理你的内容”里的个人文档区域，勾选后删除即可。注意删除是云端删除，删完之后所有设备上的副本也会跟着消失，本地做的笔记和标注如果没导出，会一起没掉。重要内容建议先导出标注再清理。

还有一个细节：文件名重复但内容不同，云端不会覆盖，会当成两份独立文档。所以版本迭代的时候，最好在文件名里带上版本号或日期，避免自己在书架上一堆同名文件里找不着北。

6.4 常见问题速查表

6.5 几条不太容易想到的避坑经验

推送前先自己预览一遍。EPUB 可以用电子书管理工具的阅读器打开看，PDF 用任意阅读器翻两页。花三十秒，能避免推过去才发现是残篇。我现在的习惯是生成完立刻预览，看完再发。

别在文件名里用特殊字符。斜杠、冒号、问号在某些环节会被过滤或导致解析失败，用短横线连接最稳。中文文件名没问题，但建议控制长度，太长的名字在设备上显示会被截断。

批量推送加间隔。连续快速发送容易被判定为异常流量，加个几秒的 sleep，稳得多。

保留一份原始文件。转换过程是有损的，尤其是 PDF 转 EPUB，表格和公式基本会乱。原始文件留着，将来想换格式或重新排版还有底稿。

定期清理云端。个人文档库不像商店书库那样有完善的管理，攒多了之后找东西很费劲。我一般一个月清一次，看完的、不打算重读的直接删，书架保持清爽，找东西也快。

7. 我自己长期用下来的几点体会

这套东西折腾到现在，最大的感受是：别追求全自动，追求的是“出错时你能快速知道错在哪”。我最早想搞一套全自动流水线，网页一收藏就自动抓取、自动转换、自动推送，结果某天开始收不到东西，排查了两小时才发现是某个环节的登录凭证过期了，而整条链路没有任何提示。后来我把自动化拆成几段，每段都有明确的输出和检查点，虽然多花几分钟，但出问题时一眼就能定位。

第二个体会是格式选择比工具选择更重要。很多人反复换工具，其实问题出在推的东西本身：一个扫描版 PDF，换十个工具也还是扫描版；一个没有目录的 EPUB，换十个扩展也还是没目录。先想清楚你要的是流式阅读还是版式还原，再决定用什么格式，最后才轮到选工具。

第三个是控制推送的量。刚开始用的时候觉得什么都能推，网页、文档、资料、论文，一股脑往设备里塞，结果书架堆了几百份，反而不知道读哪个。现在我给自己定了个规矩：只推当天或当周真要读的，读完就删，书架常年维持在十几份以内。设备是用来读的，不是用来囤的。

最后分享一个小技巧：如果你经常推同一类内容，比如每天固定的几个信息源，把它们的抓取规则、样式表、发送脚本整理成一个模板目录，换设备、换电脑的时候整个拷过去就能用。我这份模板用了三年，改过无数次参数，现在基本是“扔链接进去，跑一下，等收书”的状态，算是把这件事彻底做成了一件不占脑子的事。