把一篇网页塞进 Kindle 这件事，我前后折腾了两年多。最早只是为了通勤路上读几篇长文，后来慢慢沉淀成一套固定动作：看到值得细读的页面，点两下，第二天早上它已经躺在书架里了。很多人觉得 Kindle 推送是个挺玄的东西——要注册、要加白名单、要转格式，听起来门槛很高。其实把它拆开就三件事：一个专属的收件邮箱、一份允许发信的名单、一个能被正确解析的文件。这三件事搞明白，推送网页到 Kindle 就跟发一封带附件的普通邮件没区别。这篇内容面向的是手里有一台阅读器、想把它从"吃灰设备"变成"每日读物入口"的人，不管你是刚入手的新手，还是已经会发邮件推送、但总被排版和格式搞崩的老用户，下面这些流程和踩坑记录应该都能直接用上。

1. 先搞明白推送机制，别急着动手

1.1 推送到底走的是哪条链路

很多人对 Kindle 推送的理解停留在"发邮件"这一层，这不算错，但只对了一半。完整的链路是：内容从你的发件邮箱出发，进入服务商的个人文档服务器，服务器做一次格式识别与转换，转好的文件落到你的云端书库，最后由设备联网自动拉取下来。也就是说，你发出去的那个文件，和最终出现在屏幕上那个文件，中间隔了一次"再加工"。

理解这一点非常关键，因为它决定了后面所有的操作逻辑。为什么主题里写个 Convert 就会触发格式转换？因为服务器默认把你发的东西当"成品"直接入库，只有你明确要求，它才会动手转。为什么 PDF 推过去字小得看不清？因为 PDF 是固定版式，服务器不会去重排它，屏幕上看到的就是原页面的缩小版。为什么有的网页推过去图片全丢？因为转换器只拿到了 HTML 文本，图片链接是相对路径或者需要登录才能访问，抓不到就是抓不到。

我一般把这条链路记成"投递—识别—转换—入库—同步"五步。任何一步出问题，表现都是"没收到"，但原因可能完全不同。所以排查的时候不要一上来就frantically重发，先定位是哪一步断的，效率会高很多。

1.2 三种主流通道，各管什么场景

市面上能用的推送通道大致分三类，我做了个对照，方便你按场景选。

我的常规组合是：临时看到的好文章走浏览器扩展，质量不稳定的站点走本地工具生成 EPUB 再邮件推送，需要长期追更的用工具做定时任务。三条路各司其职，不用强行统一。

1.3 什么内容值得推，什么内容别浪费墨水

这一点很少有人讲，但我觉得比技术细节更重要。阅读器的屏幕小、翻页慢、没有超链接跳转，它天然适合线性阅读的长文本，不适合交互性强的内容。带大量可点击按钮、需要滚动加载、靠视频讲清楚的东西，推过去基本是废的。

我自己的判断标准很简单：这篇文章如果打印出来，我会不会愿意在地铁上读完？会，就推；不会，就存到稍后读里等有电脑时再看。另外，纯代码文档、需要频繁对照表格的资料、有大量公式推导的论文，推之前最好先想想——它们在六寸屏上的体验可能还不如手机横屏。

2. 动手前的三项准备，缺一不可

2.1 找到属于你的那个推送邮箱

每台设备（准确说是每个账户下的每台设备）都有一个专属的接收地址，形式通常是一串字符加一个固定的后缀。它的位置在设备的设置里，翻到"你的账户"那一栏，往下找与"发送至"相关的条目，就能看到这个地址。

这个地址有个特点：长得像邮箱，但你不能拿它当普通邮箱用，它只收不发。我第一次搞的时候犯过一个低级错误——把它当成了自己的登录邮箱，结果在自己的邮箱里找了半天收件箱，当然是空的。判断方法很简单：能收到服务器转发过来的"已接收"通知的，才是你真正的发件邮箱。

顺手做一件事：把这个地址存进通讯录，命名成"我的阅读器"。后面每次推送直接选联系人，省得反复复制粘贴，也避免手抖打错一个字符导致石沉大海。

2.2 白名单不加，发一百封也进不来

这是新手最容易卡住的地方，也是我见过最多的"我明明发了但没收到"的原因。出于防垃圾邮件的考虑，服务器默认只接收来自"已批准列表"里那些地址的文档。你用一个陌生邮箱发过去，文件会被直接丢弃，而且大概率不会给你任何退信提示——安安静静地消失，最容易让人怀疑人生。

配置入口在账户的个人文档设置页里，找到"已批准的个人文档电子邮箱列表"，把你要用的发件地址加进去。有几个细节值得注意：

• 加进去的必须是你实际发信时用的那个地址，用别名、转发地址、企业邮箱的子账号，都可能对不上。
• 大小写一般不影响，但前后空格会，粘贴完记得检查一下。
• 如果你习惯用多个邮箱（比如一个私人一个工作），就都加上，别嫌麻烦。
• 改完之后不用等，通常几分钟内生效，不需要重启设备。

提示：如果你用的是邮箱客户端的"代发"功能，实际发件人可能和你看到的不一样。稳妥的做法是先发一封纯文本测试邮件，附件带一个几十 KB 的 TXT，确认整条链路通了再推正式内容。

2.3 格式与体积的边界在哪里

支持的个人文档格式大致是这几类：EPUB、PDF、DOC/DOCX、HTML、TXT、RTF，以及常见的图片格式。其中 EPUB 的阅读体验最好，字号可调、可以重排、可以做目录；PDF 保真但不可重排；DOCX 居中，转出来的排版通常还行；HTML 和 TXT 最轻，但样式基本全丢。

体积方面，单个文件有上限，一封邮件里的附件数量也有上限，具体数值各账户可能略有差别，后台设置页会写清楚。我的经验值是单篇控制在 20MB 以内比较稳，超过这个数，转换时间会明显变长，偶尔还会卡在队列里。图片多的网页尤其要注意——很多抓取工具会把原图一并打包，一篇图集能轻松超过 50MB。

还有一个隐藏限制：转换是有排队的。同一时间推太多，后面的会等前面处理完。我曾经一次性推了十几篇，最后一篇隔了快半小时才出现，当时还以为失败了。

3. 网页推送的四条实操路径

3.1 路径一：浏览器扩展，日常最顺手的一条

这是我现在用得最多的方式。装好扩展之后，在任意网页上点一下图标，它会做三件事：提取正文、去掉导航和广告、把干净的 HTML 交给推送服务。整个过程不离开当前页面，两三次点击搞定。

几个实际操作中的心得：

第一，扩展通常有"预览"功能，强烈建议在推送前点一下。有些页面正文提取会失败，预览里能一眼看出来——比如只抓到了标题和一句摘要，或者把评论区一起抓了进来。预览花三秒，能省掉后面在阅读器上翻半天发现内容残缺的烦躁。

第二，遇到需要登录才能看的页面，扩展抓到的往往是登录墙。这种情况我会先在浏览器里登录好，再抓一次；如果还是不行，就退回路径四，手动另存。

第三，不同扩展对图片的处理策略不一样。有的会把图片压缩后内嵌，有的只保留链接。后者推过去基本是空白框，因为阅读器联网加载外链图片的成功率不高。选扩展时可以留意一下它是否内嵌图片。

3.2 路径二：官方网页入口，不用装任何东西

如果不想装扩展，官方提供的网页推送入口是第二选择。登录之后找到对应页面，把网址粘进去，可以选择直接推送或者先预览。它的好处是跨平台——在别人的电脑上、在公司机器上、在平板上，只要有浏览器就能用，不用同步扩展配置。

这条路的短板是它同样依赖服务端的正文提取能力。对于结构规整的资讯类页面，效果不错；对于前端框架渲染的单页应用，经常只抓到一片空白。判断方法很朴素：如果这个页面在浏览器的"阅读模式"下能正常显示，那推送过去大概率也没问题；如果阅读模式都是空的，就别指望推送能救回来。

3.3 路径三：邮件正文直接贴，最土但最可靠

有些短内容，比如一段公告、一篇几百字的随笔、一封值得留存的信，根本没必要折腾抓取。直接把文字复制到邮件正文，主题里写上转换指令，发过去就行。

这里有个反直觉的点：邮件正文会被转换成文档，但格式基本只剩段落。加粗、斜体、列表符号，多数会丢掉。所以如果你在意结构，就不要用这条路径，老老实实做个 HTML 或 DOCX 附件。

还有个细节，正文里的图片是不会被带过去的。图片必须在附件里，或者内嵌在 HTML 中。我试过在正文里贴一张图，结果推过去只有文字，图的位置留了个空行。

3.4 路径四：自己转一份 EPUB，排版最可控

当页面结构复杂、抓取工具反复失败，或者你希望长期保存一份排版舒服的版本，那就自己动手转。这套流程稍微重一点，但结果最稳定。

基本步骤是：浏览器里打开页面，用阅读模式或者开发者工具把正文的 HTML 拿出来，另存为一个.html文件，然后用转换工具生成 EPUB。命令行工具里，pandoc 是绕不开的选择：

pandoc article.html \ -f html \ -t epub3 \ -o article.epub \ --metadata title="文章标题" \ --metadata author="来源站点" \ --toc --toc-depth=2

参数说明一下为什么这么写。-f html -t epub3明确指定输入输出格式，避免它自己猜错；--metadata title是必须的，不写的话生成的 EPUB 在书架里会显示成一串文件名，很难看；--toc生成目录，长文必备，六寸屏上翻目录比滑动快得多；--toc-depth=2控制目录层级，只取两级标题，太深了目录本身就成了负担。

如果原文是多个页面（比如分页的长文），可以先把各页 HTML 拼成一个文件再转，或者在转换时用多个输入文件：

pandoc page1.html page2.html page3.html -f html -t epub3 -o book.epub --toc

拼的时候注意把每页重复的导航、页脚删掉，否则目录里会混进一堆"下一页""相关阅读"。

3.5 抓取失败时的降级顺序

我把降级策略固定成一条链，遇到问题就往下走一格，不重复试同一个方法：

1. 扩展抓取失败 → 换网页入口再试一次（两者的提取逻辑不同，经常一个行一个不行）。
2. 网页入口也失败 → 浏览器阅读模式确认正文是否存在，存在就手动另存 HTML。
3. 手动另存后格式乱 → 用 pandoc 转 EPUB，配合--extract-media把图片一并抽出来。
4. 图片依然丢失 → 直接打印成 PDF（浏览器的打印功能，选"另存为 PDF"），放弃重排，接受固定版式。
5. PDF 太大推不上去 → 用压缩工具降采样，或者只截取需要的章节。

这条链走下来，百分之九十的页面都能搞定。剩下那百分之十，通常是内容需要登录、或者本身就不是文章（比如一个工具页面），那也没什么推的必要。

4. 让推过去的东西"像本书"

4.1 清洗正文，去掉一切不该出现的东西

抓取工具的通病是"抓多了"。导航栏、侧边推荐、作者简介、评论区、Cookie 提示，这些在网页上是合理的，在阅读器上就是噪音。更烦的是它们经常出现在正文中间，把一段连贯的论述切得七零八落。

我的处理办法分两步。第一步是在扩展的设置里配置"排除选择器"，把常见的噪音容器（比如带nav、aside、footer这类语义标签的元素）排除掉。这一步能解决大部分问题。第二步是转 EPUB 之前，用一段脚本做二次清洗，把剩下的空段落、重复标题、内联样式清掉。

如果不想写脚本，也有土办法：把 HTML 丢进任意一个支持源码编辑的编辑器，用查找替换把<div class="ad">...</div>这类块整段删掉。笨，但对一次性任务足够。

4.2 图片、代码块和表格，三个重灾区

图片的问题前面提过，核心是相对路径和防盗链。解决思路是把图片下载到本地，改成相对路径引用，再用 pandoc 的--extract-media打包进 EPUB。这样生成的文件是自包含的，不依赖网络。

代码块的问题是缩进和换行会被吃掉。HTML 里的<pre>标签在转换时经常被当成普通段落处理，结果代码全挤成一行。解决办法是在转换时保留<pre>的结构，pandoc 对<pre><code>的处理是正确的，前提是你的源文件里标签没被破坏。如果是从网页复制的富文本，先粘到纯文本编辑器里再包标签，反而更保险。

表格是最麻烦的。宽表格在六寸屏上必然溢出，横向滚动在阅读器上体验极差。我的做法是：超过四列的表格，转成图片再插入，或者干脆拆成几个小表。听起来退步，但实际读起来顺畅得多。

4.3 封面、目录和章节切分

一份"像书"的文档，封面和目录的价值比想象中大。封面让你在书架上一眼认出它，目录让你能跳读。EPUB 里这两样都有标准做法：封面是一张图片加一个cover属性的元数据，目录是导航文档。

pandoc 转出来的 EPUB 默认没有封面。加封面需要额外的元数据参数，或者用工具做后处理。我一般懒得折腾，直接用文章标题当书名，靠书架上的文字识别，只有在整理系列文章时才认真做封面。

章节切分倒是值得花点心思。一篇一万字的长文，如果只有一个章节，翻起来很难定位。转换前把文中的二级标题标出来，让 pandoc 按标题切分，生成的 EPUB 就会自动分章。这个操作几乎零成本，收益很明显。

5. 问题排查：收不到、排版乱、图片丢

5.1 "发了没反应"的标准排查顺序

这是最高频的问题，我整理成一张表，按顺序走，基本能定位。

这里最容易被忽略的是第 5 条。推送成功后文件是先到云端的，设备需要联网才会拉取。我有一次在飞机上推了一堆，落地开机才发现全在那儿等着，白白焦虑了一路。

5.2 排版崩坏的几种典型形态

排版问题比收不到更折磨人，因为文件确实到了，只是没法看。常见的几种：

字号巨大或极小。多半是推了 PDF，或者 HTML 里带了固定的font-size。EPUB 会尊重用户的字号设置，PDF 不会。这就是我一直推荐 EPUB 的原因。

段落之间空行过多。源 HTML 里每个段落都包在<div>里并且带 margin，转换后每个 div 都成了一个块。清洗时把 div 换成 p，或者干脆去掉样式属性，就能解决。

中文乱码。编码声明缺失。手动另存 HTML 时务必选 UTF-8，文件头加上<meta charset="utf-8">。

行距过密或过疏。这是内联样式在作怪。EPUB 的正确做法是不写行距，交给阅读器控制。转换前把所有line-height属性删掉。

标题层级错乱。网页的 h1 通常只有一个，但抓取工具可能把站点名也当 h1 塞进来。转完之后目录里出现两个一级标题，看着很别扭。

5.3 一次推多篇，怎么组织才不乱

批量推送是另一个容易翻车的场景。我早期的做法是一篇一封邮件，结果书架里堆了二十个文件名，找起来极其痛苦。

后来改成两种组织方式。一种是按主题合并：把同一话题的几篇文章拼成一个 EPUB，用主题当书名，每篇当一个章节。另一种是按时间归档：每天生成一份"今日读物"，日期当书名，第二天自动覆盖不了就新建。两种方式都比散着推强得多。

合并的时候有个技巧：给每篇文章加一个分隔页，写上标题、来源、抓取时间。这样读的时候不会串篇，事后回溯也方便。

6. 进阶：把这套流程自动化

6.1 用本地工具做定时抓取

如果你有固定追更的几个站点，手动推是浪费生命。本地电子书管理工具里有"抓取新闻"的功能，本质是定时执行抓取脚本，把结果打包成一份期刊，然后可以配置成自动发送。

它的配置核心是一个"源"的定义：站点地址、抓取条数、是否保留图片、抓取时间范围。写起来不复杂，一个最小可用的源大概长这样：

class MyDailyRecipe(BasicNewsRecipe): title = "每日读物" oldest_article = 1 max_articles_per_feed = 8 feeds = [("站点名称", "https://example.com/feed")]

几个参数值得调。oldest_article = 1表示只取最近一天的内容，避免重复；max_articles_per_feed控制单次数量，太多会导致文件过大、推送超时；title是书名，建议带上日期，方便归档。

定时任务交给系统自带的任务计划就行，每天固定时间跑一次，生成完自动投递。配置一次，后面基本不用管，除非站点改版导致抓取规则失效。

6.2 自己写脚本：从抓取到投递一条龙

工具不够灵活的时候，自己写一段也不难。核心就三步：取页面、提正文、发邮件。发邮件这一步用标准库就够了：

import smtplib from email.message import EmailMessage msg = EmailMessage() msg["Subject"] = "Convert" msg["From"] = "你的发件邮箱" msg["To"] = "你的推送地址" msg.set_content("见附件") with open("article.epub", "rb") as f: msg.add_attachment(f.read(), maintype="application", subtype="epub+zip", filename="article.epub") with smtplib.SMTP_SSL("smtp.example.com", 465) as s: s.login("你的发件邮箱", "授权码") s.send_message(msg)

几个坑提前说。第一，Subject里的转换指令要单独写，不要和标题混在一起，否则可能识别不到。第二，很多邮箱服务不允许直接用登录密码发信，需要单独申请一个授权码，这个码才是 SMTP 登录要用的。第三，附件类型要写对，EPUB 的 MIME 类型是application/epub+zip，写错了有些客户端会拒收。

6.3 归档与去重，别让书架变成垃圾场

自动化跑起来之后，新的问题来了：书架越来越满，同样的文章推了两遍。我的处理方式是给每篇文章算一个指纹（标题加链接的哈希），推之前先查本地记录，重复的跳过。这个记录用简单的文本文件或者 SQLite 存就行，不需要上数据库。

云端那边也要定期清理。推过的、读完的、质量一般的，及时删掉。阅读器的存储空间有限，塞满了会影响同步速度，翻页也会变卡。我现在保持书架在三十本以内，读一本删一本，清爽很多。

最后分享一个我觉得最值的小技巧：给推送内容的文件名加上日期前缀，格式是"年月日-标题"。这样在书架按名称排序时，天然就是时间顺序，找东西快得多。这个习惯我从一开始就养成了，后来再没出现过"那篇讲什么来着，找不到了"的情况。