书源批量验证

书源验证不是首页连通性测试。有效来源至少需要完成一个真实入口到非空正文的链路。

验证阶段

1. 使用来源 checkKeyWord，缺失时统一用低风险关键词「我的」（ruleSearch.checkKeyWord 字段说明见书源字段参考）——所有书源 用同一个词，避免各源测试关键词不一致导致结果不可比；
2. 优先搜索，搜索无结果时再尝试发现；
3. 获取第一条可用书籍详情；
4. 获取目录并选择可读章节；
5. 获取非空正文；
6. 分类网络、解析、验证、登录、目录和正文失败。

并发

验证窗口持续补充任务，遵守“网络配置 → 验证并发”的用户设置，不使用固定批次屏障。 低电量或 serious/critical thermal 状态会动态收缩并发，应用退到后台时暂停未完成工作， 回前台后继续。

结果解释

结果	含义
通过	搜索/发现、详情、目录和正文链路成功
部分可用	某入口成功但完整链路缺失，或需要后续人工确认
需要交互	登录、CAPTCHA 或 Cloudflare 需要用户操作
抓取异常	规则执行、网络或解析失败；查看阶段和诊断字段

失败分组与失败类型

失败会同时打上两套标签，分别回答“哪个环节坏了”和“大概是什么原因”：

失败分组（写回 bookSourceComment，定位到具体规则字段）：

搜索链接规则为空 / 搜索失效 / 搜索目录失效 / 搜索正文失效
发现规则为空 / 发现失效 / 发现目录失效 / 发现正文失效
校验超时 / js失效 / 网站失效

失败类型（用于 UI 里“一键筛选可修复问题”）：

禁用源 / TLS / 404 / 405 / 反爬 / 规则空 / 超时 / ATS / 其他

例如一个书源报 搜索正文失效 + 反爬，通常意味着搜索链路本身没问题（能拿到列表和详情）， 但正文页触发了反爬拦截——排查方向是正文规则或 User-Agent/Referer，而不是重新检查 ruleSearch。反过来 搜索失效 + 规则空，说明问题出在 ruleSearch.bookList 之类的 字段本身缺失或写错，先去看规则而不是怀疑网络。

批量验证一批书源后，ImportResult 风格的汇总（通过数/部分可用数/失败数）可以按失败类型 分组，优先修「规则空」「404」这类明确可自己修的，「反爬」「ATS」往往需要专门处理 （见 Cloudflare 与反爬绕过实战），「TLS」则大概率是站点证书 或系统信任链问题，不是书源规则能解决的。

离线 Python 验证器用于回归，不等于 iOS App 运行成功。最终需要相同 runtime 语义和真机 回放。