空壳浏览器 + 规则翻译
阅读类应用本身不存储任何小说内容，书源是一套可编程规则，把第三方站点的搜索、详情、目录、正文实时“翻译”成统一书籍模型。
不是功能罗列，而是从规则编写、调试、导入到长期维护的真实约束条件
阅读类应用本身不存储任何小说内容，书源是一套可编程规则，把第三方站点的搜索、详情、目录、正文实时“翻译”成统一书籍模型。
书源调试遵循“定义预期 → 编写规则 → 调试验证”的循环。每个标签页必须单独通过验证才能推进，不允许批量写完再调试。
网络导入最推荐、更新最快；本地 JSON 导入适合离线稳定场景；二维码导入一键完成、出错率最低。三者共用同一套书源 JSON 格式。
内置“校验书源”可批量锁定失效项，调试页则精确到具体规则环节。搜索无结果、详情空白、连接超时对应不同的修复路径。
2026 年判例将书源认定为“预设了抓取规则的深度链接指令包”。技术本身不构成定罪核心，商业化变现才是关键分界线。
原版仓库停更后，Sigma、Beta、Max、MD3、鸿蒙版等社区分支持续高频发版。所有版本共用同一套书源规则与进度备份。
从基本语法到调试排错，挑几个值得反复看的讲解视角
从搜索地址的构造开始，拆解关键词编码、列表选择器与字段提取的衔接方式，适合作为第一个可运行书源的起点。
选择器看起来对了但结果为空？打印局部 HTML、检查属性名变体、用 java.log() 定位环节，把“猜”替换成可复现的排查步骤。
梳理当前活跃分支的定位差异：新手求稳、功能折腾、听书优先、鸿蒙适配各有对应版本，书源生态本身完全通用。
对比三种导入方式的操作步骤与适用场景。网络导入追更新，本地导入求稳定，二维码导入降低手动出错概率。
搜索无结果、目录空白、连接超时分别对应不同的病灶。从校验书源的批量体检入手，再用调试页精确定位到具体规则。
对比不同规则模式在搜索列表、目录、正文提取中的适用场景，以及 && 合并、|| 回退、@put 变量传递的组合用法。
判例、分支与供给端变化，书源生态正在经历的几件真事
开发者葛某某、吴某某分别获刑二年与一年九个月。判决并未否定阅读器工具本身，而是将商业化变现行为作为定罪核心。
查看详情 →累计 4.7 万 Star 的 gedoor/legado 仅保留一则公告，代码与安装包全部移除。但 GPL v3.0 协议为社区分支留下了接棒空间。
查看详情 →LegadoTeam、MD3、Sigma、Max 等分支在 8 月保持发版节奏。所有版本共用书源规则与 WebDav 备份，换客户端不需要换书源。
查看详情 →判决之后，靠收费书源变现的社群大规模解散。书源失效频率上升，不仅是网站改版问题，也与维护者激励结构的变化直接相关。
查看详情 →七条活跃分支覆盖安卓与鸿蒙双平台。新手求稳可看 Beta 或 Sigma，功能折腾选 Max，颜值与 Material Design 3 对应 MD3。
查看详情 →导入、去重、换源都以 bookSourceUrl 为准，清洗后的域名不能替代它。ruleSearch、ruleBookInfo、ruleToc、ruleContent 构成最小可用链路。
查看详情 →每条回答拆成五个独立信息点，方便快速定位关键结论
不是。阅读类应用本身不存储任何小说正文，它的本质是一个“空壳浏览器”，书架和阅读界面展示的是对第三方站点内容的实时解析结果[reference:0]。
书源是一套可编程规则，负责把小说网站的搜索页、详情页、目录页、正文页“翻译”成统一的书籍模型，包括书名、作者、封面、简介、目录和正文[reference:1]。
因此书源是阅读器的“灵魂”而非附属品：没有书源，客户端只是一个无法输出内容的空容器；有了书源，它才具备聚合阅读能力[reference:2]。
从数据结构看，书源通常是一个 JSON 数组文件，每一条记录是一个完整的书源对象，包含 bookSourceUrl、searchUrl、ruleSearch、ruleBookInfo、ruleToc、ruleContent 等字段[reference:3][reference:4]。
这也意味着书源的有效性不取决于客户端版本，而取决于目标网站的页面结构是否与规则匹配——网站改版，规则就可能失效，与客户端是否更新没有必然关系。
TDD 在书源制作中对应“定义预期 → 编写规则 → 调试验证”的循环，每个标签页必须通过验证才能进入下一个，未验证的规则被视为错误规则[reference:5]。
标准标签页顺序是：正文 → 目录 → 详情 → 搜索 → 发现，每一页单独完成 TDD 循环，不允许跳步或合并验证[reference:6]。
不能批量写完再调，是因为书源规则是一套 DSL（领域特定语言），选择器、属性名、编码、请求头的细微差异都会导致整条链路断裂，事后排查成本远高于逐页验证[reference:7]。
调试失败时先用 java.log() 排查，而不是直接改选择器；同时不允许删除模板中的注释，注释包含字段约束和格式要求，删除会直接导致后续填写错误[reference:8][reference:9]。
手机与电脑需处于同一局域网，并在客户端开启 Web 调试功能，真实环境测试才是最终验证，模拟引擎的结果不能替代实机行为[reference:10][reference:11]。
第一步不是手动改规则，而是用客户端内置的“校验书源”做批量体检。校验会按域名、搜索、发现、详情、目录、正文逐项走一遍，失败项会被直接标记出来[reference:12]。
搜索无结果或提示“未获取到书籍”，优先检查 searchUrl 和 bookList 规则，常见原因是搜索接口变更或触发风控[reference:13]。
能搜到但详情或目录空白，通常对应详情页/目录页结构改版，需要检查 tocUrl 和 chapterList 规则[reference:14]。
提示网络错误或连接超时，先确认域名是否仍可访问，再检查 Header、Cookie 和登录态；登录态失效可在书源管理页执行“登录”或清除 Cookie 后重新登录[reference:15][reference:16]。
域名变更的典型特征是“搜索规则返回空但网页能打开”，此时需要把规则里的旧域名替换为新域名，并同步修改 bookUrlPattern[reference:17]。
最推荐的路径是网络导入：在“我的 → 书源管理 → 右上角菜单 → 网络导入”中粘贴 JSON 地址，等待加载后勾选需要的书源即可，书源最新、维护成本最低[reference:18]。
本地导入适合离线或网络受限场景：将 shuyuan.json 下载到手机任意可找到的位置，通过“本地导入”选择文件完成导入，不依赖在线地址的实时可用性。
二维码导入的出错率最低：在书源管理页选择二维码导入并扫描分享页生成的二维码，适合分享和跨设备快速配置[reference:20]。
三种方式共用同一套书源 JSON 格式，支持数组、{"data":[...]} 和 {"bookSourceItems":[...]} 三种导出结构，可多选文件合并导入[reference:21]。
无论哪种方式，导入后都需要逐项校验；HTTP 200 不等于规则可用，最小可用书源跑通“搜索 → 详情 → 目录 → 正文”链路后才具备实际阅读价值[reference:22]。
定罪核心不是“开发了一个阅读器”，而是通过它牟利。判决逻辑将商业化变现作为关键分界线，而非工具本身的存在[reference:23]。
该案中，开发者葛某某与合伙人通过公众号和社群积累了近 200 万粉丝，以打赏、广告、电商团购等方式非法获利 100 余万元，这被检方认定为“不是中立的技术提供者”[reference:24]。
书源在该案中被定性为“预设了抓取规则的深度链接指令包”，本质是深度链接技术的应用，而不是传统的直接上传、存储侵权内容[reference:25]。
判决书显示，近 4000 部作品与权利人独家授权作品的内容相似度超过 90%，这构成了侵权的实质性要件之一[reference:26]。
判决之后，靠收费“卖书源”变现的群组大量解散，书源供给端收缩，这也从侧面印证了红线在于变现行为，而非规则技术本身[reference:27]。
靠社区分支接棒。原版 gedoor/legado 在 2026 年 5 月发布公告并删除内容后，GPL v3.0 开源协议允许社区二次开发，Sigma、Beta 两支主流队伍接管了开发节奏[reference:28][reference:29]。
当前活跃分支至少包括 LegadoTeam/Beta、Sigma、Max、MD3、R、C 和鸿蒙版，覆盖安卓与鸿蒙双平台，8 月仍有持续发版[reference:30]。
所有分支共用同一套书源生态：书源规则、阅读进度、WebDav 备份完全通用，换客户端不需要重新配置书源[reference:31]。
选择建议：新手求稳看 Beta 或 Sigma；功能折腾选 Max；听书优先考虑 R；Material Design 3 颜值向选 MD3；纯血鸿蒙选鸿蒙版[reference:32]。
分支维护者的共同底线是不通过书源变现。社区普遍认为，自费维护、不变现的路线与判例逻辑之间保持了安全距离，这也是生态得以延续的重要前提[reference:33]。
关于规则、调试与分支选择的真实讨论