Kindle推送与网页转电子书全链路：格式、白名单、排版与排错

做 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 三通道横向对比与选型建议通道单文件上限支持格式多设备同步适合场景邮件附件一般在 25MB 量级以页面提示为准EPUB、PDF、DOCX、TXT、HTML、图片等支持手机随手发、脚本自动化网页/客户端上传明显更大通常在百 MB 量级与邮件基本一致额外更稳支持大体积 PDF、扫描件、图文混排浏览器扩展受其上传递道限制多为转换后的 EPUB 或 PDF支持单篇网页长文、系列文章USB 拷贝无硬上限理论上都能塞不支持应急、离线、超大文件选型的逻辑其实很简单文件小、要自动化走邮件文件大、要省事走网页上传内容在网页上走扩展或脚本。别指望一条通道解决所有场景混着用才是常态。我自己是日常网页长文走扩展扫描版 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 再推。格式排版还原可调字号适合内容建议EPUB中完全可调小说、长文、网文首选PDF高不可调可缩放论文、扫描件、图表先重排页面DOCX中低部分可调办公文档、笔记应急TXT无可调纯文字草稿应急MOBI/AZW3中部分可调旧资源先转 EPUB3.2 一次完整的邮件推送演示流程本身很短但每一步都有讲究准备文件。确认格式是 EPUB 或 PDF文件名建议用“书名 - 作者”这种结构因为很多情况下文件名会直接影响书架上显示的标题。新建邮件。收件人填你的 Kindle 接收邮箱主题可以留空也可以写书名部分场景下主题会被当作标题使用正文留空即可写内容没用。添加附件。单个文件直接拖进去多个文件注意总体积别超限。发送。用白名单里的邮箱发。等待入库。通常几分钟到十几分钟。期间可以在网页端“管理你的内容”里刷新看有没有出现。设备同步。设备连 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 端口通常 465STARTTLS 通常 587 SENDER your_mailexample.com # 必须在已批准发件人列表里 AUTH_CODE os.environ[MAIL_AUTH_CODE] # 授权码走环境变量别硬编码 KINDLE_MAIL your_namekindle.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, maintypeapplication, subtypeepubzip if path.lower().endswith(.epub) else octet-stream, filenameos.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, timeout20, 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(uidstyle, file_namestyle/main.css, media_typetext/css, contentstyle) chapter epub.EpubHtml(titletitle, file_namechap_01.xhtml, langzh) chapter.content fh2{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 四条路线怎么选路线上手成本内容完整度排版可控性适合场景浏览器扩展极低中低偶尔推单篇打印成 PDF低高中图文混排、要还原版式稍后读加定时投递低中低每天批量读、追求省心自建脚本高高高长期、大量、有格式要求我的实际组合是随手看到的用扩展重要的长文用打印每天固定的几个源用 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 常见问题速查表现象最可能原因处理动作发了完全没反应云端无记录发件人不在白名单 / 未完成验证加白名单并点验证链接云端有记录设备没下载设备未联网 / 关闭了个人文档同步连 Wi-Fi手动同步一次收到但内容是乱码TXT 编码不匹配另存为 UTF-8 重推收到但满屏空白PDF 加密 / 扫描件无文字层解除保护或改传原件图片全部丢失图片用了外链或路径错误改为内嵌资源重新生成排版极差正文被淹没未做去噪用阅读模式或提取算法重做书架出现多个同名文件重复推送在内容管理里删掉多余副本推送速度极慢文件体积过大 / 高峰排队压缩图片错峰推送打开后字号无法调整推的是 PDF换 EPUB 或重排 PDF 页面6.5 几条不太容易想到的避坑经验推送前先自己预览一遍。EPUB 可以用电子书管理工具的阅读器打开看PDF 用任意阅读器翻两页。花三十秒能避免推过去才发现是残篇。我现在的习惯是生成完立刻预览看完再发。别在文件名里用特殊字符。斜杠、冒号、问号在某些环节会被过滤或导致解析失败用短横线连接最稳。中文文件名没问题但建议控制长度太长的名字在设备上显示会被截断。批量推送加间隔。连续快速发送容易被判定为异常流量加个几秒的 sleep稳得多。保留一份原始文件。转换过程是有损的尤其是 PDF 转 EPUB表格和公式基本会乱。原始文件留着将来想换格式或重新排版还有底稿。定期清理云端。个人文档库不像商店书库那样有完善的管理攒多了之后找东西很费劲。我一般一个月清一次看完的、不打算重读的直接删书架保持清爽找东西也快。7. 我自己长期用下来的几点体会这套东西折腾到现在最大的感受是别追求全自动追求的是“出错时你能快速知道错在哪”。我最早想搞一套全自动流水线网页一收藏就自动抓取、自动转换、自动推送结果某天开始收不到东西排查了两小时才发现是某个环节的登录凭证过期了而整条链路没有任何提示。后来我把自动化拆成几段每段都有明确的输出和检查点虽然多花几分钟但出问题时一眼就能定位。第二个体会是格式选择比工具选择更重要。很多人反复换工具其实问题出在推的东西本身一个扫描版 PDF换十个工具也还是扫描版一个没有目录的 EPUB换十个扩展也还是没目录。先想清楚你要的是流式阅读还是版式还原再决定用什么格式最后才轮到选工具。第三个是控制推送的量。刚开始用的时候觉得什么都能推网页、文档、资料、论文一股脑往设备里塞结果书架堆了几百份反而不知道读哪个。现在我给自己定了个规矩只推当天或当周真要读的读完就删书架常年维持在十几份以内。设备是用来读的不是用来囤的。最后分享一个小技巧如果你经常推同一类内容比如每天固定的几个信息源把它们的抓取规则、样式表、发送脚本整理成一个模板目录换设备、换电脑的时候整个拷过去就能用。我这份模板用了三年改过无数次参数现在基本是“扔链接进去跑一下等收书”的状态算是把这件事彻底做成了一件不占脑子的事。