折腾开源阅读APP这件事，我从最早用手机自带阅读器，到后来陆陆续续试过七八个商业小说APP，绕了一大圈，最后还是回到这个开源项目上。原因说起来很简单：它本身不提供任何内容，只是一个干净的阅读外壳，所有的"书"都来自你自己导入的书源。这意味着没有开屏广告、没有会员弹窗、没有"试读三章请付费"，2613个书源听起来挺唬人，但本质上就是2613套"从哪里、按什么规则把正文抓下来"的配置文件。我从2019年前后开始攒书源，手机里删了又装、装了又删，最后稳定下来的也就几十个能长期用。这篇就把我这些年折腾阅读APP、书源格式、导入方法、TTS 引擎和一堆踩坑经验完整梳理一遍，不管你是第一次听说还是已经用过一阵子，应该都能捞到点有用的东西。
1. 开源阅读APP到底是干什么的：先搞懂它的底层逻辑
1.1 壳与数据分离：为什么它敢说"无广告"
理解这个软件，最关键的一句话就是：它是壳，不是内容源。APP本体是一个托管在代码托管平台上的开源项目，任何人可以下载源码、自己编译、自己改。作者没有服务器要养，没有版权内容要买，也没有广告商要接，所以它天然就不需要靠弹窗和会员来变现。你打开它，书架是空的，搜索是搜不出结果的，因为这时候它只是一个空壳。
内容从哪来？从书源来。书源是一份配置文件，里面写清楚了某个网站的搜索接口长什么样、列表怎么解析、目录页的章节链接怎么提取、正文段落该怎么抓。你把这份配置导入APP，APP就按图索骥，去那个网站把内容抓回来，排版后展示给你看。所以同一个APP，导入不同的书源，能搜到的东西、抓取的速度、正文的干净程度完全不一样。很多人第一次用觉得"怎么搜不到书"，十有八九不是软件的问题，而是书源没导入、没启用，或者导入的那批已经失效了。
这个设计的好处是极强的可扩展性。今天某个站点倒了，你换一个书源就行，软件本身不用动。坏处也很明显：书源需要维护，站点一改版，规则就可能失效，这是所有用这类工具的人都躲不开的日常。
1.2 和市面商业阅读APP的正面对比
我把两类产品放在一起做了张表，方便你直观判断自己该选哪条路。需要提前说明的是，下面说的都是功能层面和使用体感，不涉及任何版权判断，正版付费阅读永远是值得支持的方向。
| 对比项 | 开源阅读APP | 典型商业阅读APP |
|---|---|---|
| 广告 | 本体无广告 | 开屏、章节间常见 |
| 会员体系 | 无 | 有，部分内容付费 |
| 内容来源 | 自己导入的书源 | 平台自有书库 |
| 格式支持 | 支持导入 TXT、EPUB、部分 MOBI | 一般仅平台内内容 |
| 换源 | 一键换源，多源对比 | 不支持 |
| 语音朗读 | 可接系统或第三方 TTS | 平台内置，音色固定 |
| 隐私 | 无账号，数据本地或自建同步 | 需登录，数据在云端 |
| 上手门槛 | 需要理解书源概念 | 装完即用 |
| 维护成本 | 书源会失效，需不定期更新 | 无 |
从表里能看出来，它把"内容"这一块完全交给了用户。你要省心，商业APP更合适；你要的是自由、干净、可控，那这个开源壳子才是你的菜。我个人两个都用，追正版新书用商业APP，看一些冷门、跨平台的内容就用它。
1.3 什么人适合折腾，什么人真的别碰
用了这么多年，我大概能判断出谁适合、谁不适合。
适合的：
- 看书口味杂，一个平台满足不了，经常要在好几个站之间切换的人；
- 对广告和弹窗极度敏感，宁可花时间研究配置也不想看开屏的人；
- 喜欢本地导入 TXT、EPUB，自己整理书库的人；
- 对隐私比较在意，不想注册账号、不想让阅读记录上云的人；
- 愿意每周花五分钟维护一下书源的人。
不太适合的：
- 只想"装完就能看"，不想理解任何概念的人；
- 完全不能接受"某天突然搜不到书，需要换源"的人；
- 需要平台级正版保障、想要作者分成支持的人。
先把预期摆正，后面用起来就不会有那么多落差感。这个软件不是"万能免费阅读器"，它更像一把瑞士军刀，好用，但你得会用。
2. 书源文件长什么样：JSON结构与抓取原理拆解
2.1 一个最小可用书源的结构
书源本质是一个 JSON 对象，几个核心字段撑起全部逻辑。下面这个示例我用了保留域名example.com，只是为了让结构看得清楚，字段含义是通用的：
{ "bookSourceName": "示例站点", "bookSourceUrl": "https://www.example.com", "bookSourceGroup": "自用", "bookSourceType": 0, "searchUrl": "/search?keyword={{key}}&page={{page}}", "ruleSearch": { "bookList": "@css:.book-item", "name": "@css:.book-name@text", "author": "@css:.author@text", "bookUrl": "@css:a@href", "coverUrl": "@css:img@src", "intro": "@css:.intro@text" }, "ruleBookInfo": { "name": "@css:h1@text", "author": "@css:.info .author@text", "intro": "@css:#intro@text", "tocUrl": "" }, "ruleToc": { "chapterList": "@css:#list dd a", "chapterName": "@text", "chapterUrl": "@href" }, "ruleContent": { "content": "@css:#content@text", "nextContentUrl": "" } }几个字段单个拆开看：bookSourceUrl是站点主域名，所有相对路径都基于它拼接；searchUrl里的{{key}}会被替换成你搜索的关键词，{{page}}是页码；ruleSearch负责在搜索结果页里定位每一本书；ruleBookInfo处理详情页；ruleToc抓目录；ruleContent抓正文。这四段就是书源的骨架，缺一段这个源就不完整。
注意：书源里的域名一定是真实存在的公开网站地址，导入前先确认域名能正常打开，域名都打不开的书源，规则写得再漂亮也没用。
2.2 四段式规则：搜索、详情、目录、正文各管什么
搜索规则决定你能不能"搜到"。它的核心是bookList，也就是"一条搜索结果"的选择器。选错了，可能整个搜索页只抓到一条或者一条都抓不到。列表里的name、author、bookUrl是必备三件套，bookUrl尤其关键，它是通往详情页的钥匙，取错了会导致点进去就报错。有些站点搜索结果直接就是章节页，这时候bookUrl指向的就是目录，逻辑上一样成立。
详情规则负责补全书名、作者、简介、封面这些信息。有的站点详情页信息很全，有的很简陋，甚至有的源干脆把详情页规则留空，直接从搜索页带过来的信息拼凑。这不算错，只是体验差一点。
目录规则是最考验规则功底的地方。chapterList要能选中所有章节节点，chapterName取章节名（一般是@text），chapterUrl取章节链接（一般是@href）。难点在于很多站点的目录是分页的，或者正文页里直接带下一章链接，这时候就要靠nextContentUrl这类"下一页"字段来补。我见过不少书源，正文只能读一章，就是目录或下一章规则没配好。
正文规则的目标是把纯净的正文抠出来。理想情况下content一个选择器就能选中<div id="content">里的所有段落，但现实里很多站点会在正文里塞推广链接、作者的话、随机水印，所以还要配合字符串替换把杂七杂八的东西清掉。
2.3 规则语法速览：正则、CSS、XPath 都要懂一点
书源的规则语法其实是混合体，这是新手最容易懵的地方。常见的几种写法：
- 默认正则式：早期书源大量使用正则提取，比如
class="book-name">(.*?)</a>，直接把匹配到的捕获组当结果； @css:前缀：走 CSS 选择器，比如@css:.list li a@text，@text表示取文本，@href、@src表示取属性；@json:前缀：针对返回 JSON 的接口，用 JSONPath 取值；@XPath:前缀：走 XPath 路径；##替换：在取到结果后做二次清洗，比如@css:#content@text##广告|推广，把"广告""推广"这两类词删掉；{{}}变量：用来拼接动态参数，搜索关键词、页码、作者名等都可能用到。
理解了这个混合体系，你再看任何一份书源，就能大致判断它写得规不规范。一般来说，用@css:的比纯正则可读性好得多，纯正则的书源改起来非常痛苦，因为一旦站点结构变了，你要重新推一遍正则。
2.4 判断一个书源值不值得留的硬指标
不是书源越多越好。2613个听起来壮观，但实际上能稳定用的可能不到十分之一。我通常按这几个指标筛：
- 搜索能否出结果：拿一个常见关键词测，比如随便一个高频词，能搜出条目才算活着；
- 正文是否干净：点进去看，有没有大量站名水印、随机字符、分段粘连；
- 目录是否完整：多看几本书，确认不是只能抓最近几章；
- 是否需要登录：需要登录才能看正文的源，直接用不了，除非站点开放了游客接口；
- 抓取速度：太慢的源看书会一直转圈，体验极差；
- 是否支持换源：能和其他源互相印证的书，通常质量更稳。
我一般会保留 20 到 40 个通过上面测试的源，够用了。剩下的全删，不然每次搜索要等几百个源轮询一遍，反而拖慢速度。
3. 书源导入实操：从2613条到真正可用的书架
3.1 导入前的准备与格式确认
书源导入的格式，实际用到的就那么几种：JSON 文件（单个源或源数组）、TXT 文本（一行一个链接）、网络链接（指向一个 JSON 地址）、二维码（扫码导入）。你拿到别人的"2613个书源合集"，先别急着导入，做两件事：
第一，看一下文件编码和格式。如果是一个大 JSON 数组，导入前用编辑器打开确认方括号闭合正常，中间没有多余逗号，否则导入会报"数据格式错误"。第二，确认里面没有重复的bookSourceUrl。重复导入同一个源，APP 会提示跳过，但大量重复会让列表非常乱，最好先去重再导。
提示：大合集尽量在电脑上先整理，用文本编辑器做全局替换和去重，比在手机上一条条删快得多。
3.2 本地文件导入的标准步骤
以常见的开源阅读类APP为例，本地导入路径大体一致：
- 打开APP，进入"书源管理"或"我的-书源管理"；
- 点右上角的菜单，选择"本地导入"或"从文件导入"；
- 系统会拉起文件选择器，找到你放好的
.json或.txt文件； - 选中后APP会解析，解析完成会提示"发现 N 条书源，是否导入"；
- 确认导入，等待进度条走完；
- 回到书源列表，检查是否全部勾选为启用状态。
整个流程最常出问题的是第 4 步。如果文件里有非法字符、编码是 GBK 而APP按 UTF-8 解析，就会直接失败。遇到这种情况，用编辑器把文件另存为 UTF-8 编码，基本能解决。
3.3 网络导入与二维码导入怎么用
网络导入适合别人给你一个在线地址的场景。在书源管理里选"网络导入"，把形如https://xxx/booksource.json的地址粘贴进去，APP会自己下载并解析。注意地址要能直接访问到原始 JSON，不能是需要登录才能看的页面，也不能是网盘分享页。
二维码导入适合手机之间传递。把书源内容生成二维码，在APP里选"二维码导入"，扫码即可。这个方式一次能带的量有限，适合分享几个精选源，不适合导几千条的大合集，二维码会复杂到扫不出来。
我个人的习惯是：大合集走文件导入，精选源走二维码或者剪贴板。剪贴板导入也很方便，复制一段 JSON 内容，在书源管理里选"从剪贴板导入"，APP会自动识别。
3.4 2613个书源怎么筛选：校验、分组、去重
导入完成只是开始，真正的功夫在筛选。我的做法是：
第一步，批量校验。大多数阅读APP在书源管理里有"校验书源"功能，它会拿一批测试关键词去跑每个源，能出结果的标记为有效，出不来的标记为失效。跑一遍动辄十几分钟，但比手动一个个点强太多。
第二步，按分组归类。把通过的源按类型分组，比如"常用""备用""漫画""出版"。分组的好处是一键切换搜索范围，不用每次全库轮询。
第三步，去重。重复源主要表现为域名相同、规则相似。去重标准是看bookSourceUrl，相同域名且规则明显重复的只留一个。
第四步，定期复检。我大概每隔一个月跑一次校验，把新失效的清掉。别攒，攒到几百个失效源一起搜，速度会让人抓狂。
4. 阅读体验优化：TTS、排版、缓存一个都别落下
4.1 TTS语音引擎怎么挑，这事有讲究
TTS（文字转语音）是这个软件很加分的一块。它本身不带语音引擎，靠调用系统或第三方 TTS。我用下来，选择逻辑是这样的：
- 系统自带 TTS：优点是零配置、稳定、耗电低，缺点是音色机械，长句断句偶尔别扭。适合通勤路上随便听听；
- 第三方 TTS 应用：很多是开源项目，支持导入更自然的音色模型，中文朗读的流畅度明显好一截。配置时需要在系统设置里把默认 TTS 引擎切换过去，再回到阅读APP里把朗读引擎指定为它；
- 多引擎组合：有的开源 TTS 支持同时挂多个引擎，按语言或场景切换，比如中文用 A、英文用 B。
调 TTS 时我关注三个参数：语速别超过 1.2 倍，再快就容易吞字；音调默认就好，调高会显得尖；停顿，长句的断句能力取决于引擎本身，如果读起来断得奇怪，可以在阅读APP里把"按标点分段"打开，让它把长句拆短再送进 TTS。
注意：第三方 TTS 大多需要额外的语音数据包，首次使用要联网下载，下载完离线也能用。别在流量套餐里手滑下几十兆的模型。
4.2 排版、字号和翻页的调优
排版这块看起来琐碎，但直接影响你每天看书的舒适度。我固定的几套设置：
- 正文字号：手机用 18sp 左右，平板可以到 22sp，眼睛不累；
- 行距：1.5 倍是舒适区间，太密会累，太疏翻页频繁；
- 段间距：适中，能让长段落有呼吸感；
- 背景色：白天用米黄，夜里用深灰或纯黑，比纯白背景护眼；
- 翻页模式：我偏爱上下滑动，比仿真翻页更省事，也更容易控制阅读节奏。
这些设置都能在阅读界面的排版菜单里调，调好后一般会记住，不用每次改。有人喜欢用阅读主题一键切换，我建议先手动调一次，理解每个参数在干什么，再决定用不用主题包。
4.3 离线缓存与失效书源的处理
离线缓存对通勤党太重要了。在目录页长按或者选中"缓存全部"，APP会把已抓到的章节存到本地。缓存完就能断网看。要注意的是，缓存依赖书源当时能不能抓到内容，如果缓存那一刻正好源失效，缓存下来的就是空白，得回头重新抓。
失效书源的判断有几个明显信号：搜索没结果、点开章节一直转圈、正文一片空白、提示"内容为空"。遇到这些，别急着重装APP，先在书源管理里做一次校验，大概率是那批源的问题。确认是源的问题后，去换一个可用的源，或者用"换源"功能让APP自动在已启用的源里找一个能抓的。换源功能是这个软件最实用的功能之一，同一本书换三个源，总有一个能读。
5. 常见问题与排查技巧实录
5.1 搜索为空、正文空白、乱码怎么破
这三类是我遇到频率最高的问题，排查看下表就够用：
| 现象 | 最可能原因 | 排查动作 |
|---|---|---|
| 搜索完全没结果 | 书源全部失效或未启用 | 检查启用状态，跑一次书源校验 |
| 搜到但点进去报错 | 详情页规则失效 | 换一个源读同一本书 |
| 目录能看但正文空白 | 正文规则失效或被反爬 | 换源，或检查正文是否需要 referer |
| 正文出现乱码 | 站点编码非 UTF-8 | 在规则里声明编码或换源 |
| 只能读前几章 | 目录分页未处理 | 检查是否有下一页规则 |
| 朗读没声音 | TTS 引擎未授权或未选 | 检查系统 TTS 设置和APP内引擎选择 |
排查顺序永远是：先看源是否启用，再看源是否失效，最后才怀疑APP本身。我见过太多人一上来就重装APP，其实问题全在源那边。
5.2 批量校验与长期维护的正确姿势
书源维护不是一次性的活。我的节奏是：
- 每周：随手用一次换源功能，看哪些源最近不行了；
- 每月：跑一次全量校验，清掉失效源；
- 换季时：整体更新一次合集，网上流传的"最新书源合集"更新挺快，挑几个口碑好的补充进来。
校验时建议分批跑，比如先跑 200 个，看通过率再决定要不要继续，别一上来就把几千个全跑一遍，容易卡死。另外，校验用的测试关键词也要换着来，单一个词可能正好是某个站的冷门词，会误判。
5.3 独家避坑清单：这些坑我替你踩过了
最后把我这些年真实的坑列一下，都是文档里不会写的：
- 别贪多。书源不是越多越好，几百个失效源混在里面，搜索一次能等半分钟。精简到几十个足够用；
- 别在刚导入完就批量离线缓存。先手动读两本，确认源是活的，再缓存，不然缓存一堆空白；
- 备份很重要。书源列表、阅读进度、书架，导出一次 JSON 存到网盘或本地，换手机时能省大事；
- 注意隐私和账号。有些源要求登录，能不登就别登，也别在源里填自己的账号密码；
- 尊重内容来源。书源采集的是公开页面，自用可以，拿去商用或者大范围传播要谨慎，版权意识还是要有的；
- TTS 别开太大声。长时间戴耳机听书伤耳朵，音量控制在六成以内比较舒服。
6. 一些长期使用之后的想法
用到现在，我对这套东西的态度已经比较平和了。它不是那种"装上就一劳永逸"的神器，更像是一个需要你定期打理的私人书库。你把书源当成书架上的书脊，定期整理一下，它就安安静静地给你干活；你放着不管，某天想看书的时候它就会告诉你"搜不到"。所以我的建议一直是：先花一个晚上把书源体系搭好，之后每周花五分钟维护，剩下的时间就纯粹用来读书。这个投入产出比其实相当高。
还有一个我个人特别喜欢的用法——把本地 TXT 和 EPUB 混着书源内容一起放在书架上。想看的出版书、网上追的连载、随手存的文档，全在一个界面里，阅读进度还都能同步。这种"自己的图书馆"的感觉，是商业APP给不了的。真要说遗憾，就是书源这件事终究要靠社区里一群人的持续付出，哪天大家都不更新了，这套玩法也就慢慢凉了。所以遇到好用的源，偶尔也记得给作者或分享者点个赞，这大概就是开源生态最朴素的正循环。
