ziyuanzhan

影视采集源的「活体目录」：ziyuanzhan 技术拆解

项目背景与痛点

中文影视聚合生态里有一条隐秘但极其关键的链路：maccms（苹果CMS）采集接口。几乎所有的聚合播放器、TVBox 类客户端、自建影视站，底层都挂着一批形如 api.php/provide/vod/?ac=videolist 的采集源。这些源由"采集联盟"（非凡、量子、最大、黑木耳之类的资源站群）提供，特点是：数量多、寿命短、域名漂移频繁、接口偶尔改版、返回的 m3u8 时好时坏。

于是每个折腾过 LibreTV、MoonTVPlus 的人都经历过同一件事：手工维护一份 JSON 源列表，然后每隔几天去逐个点开、删掉挂掉的、补上新的。 这份列表本质上是"快照"，而采集源的状态是"流"——两者的错配就是全部痛点的来源：客户端里一堆黑屏条目、播放器加载转圈、用户体验断崖式下跌。

ziyuanzhan 的定位正是填这个缝隙：它不是又一个资源站导航页，而是一个对采集联盟源做持续可用性探测、并把结果按下游客户端格式分发出去的中间层。说白了，它把"人工点开试试"这件事自动化了。

核心技术揭秘

从项目描述的三段式（收集 → 监控 → 支持多客户端）可以推断，其架构是一个典型的三层数据管道：适配采集 → 并发探测 → 格式化分发。

第一层的关键是适配器抽象。 不同联盟的返回结构差异极大：有的走 maccms 标准 ac=list 返回 XML/JSON，有的直接吐一个 txt 播放列表，有的需要特定 UA 或 Referer 才给数据。合理的做法是为每类源实现一个 Adapter，把异构响应归一化成统一的内部描述符（源名、基址、接口类型、鉴权头、内容分类），上层探测逻辑只面对这一个模型。这一层的工程量往往被低估——它决定了项目能否跟上联盟频繁的接口变种。

第二层才是真正的技术难点：探测不能只 ping 接口。 大量采集源存在"接口 200 但内容全挂"的情况：ac=videolist 正常返回几百条数据，点进去 m3u8 却是 403 或已被切片服务器下线。因此健壮的探测必然是两段式：先探列表接口拿状态码与数据量，抽样一两条播放地址，再对 m3u8 做二次校验——拉取 playlist 头部，检查是否包含 #EXT-X- 标签、是否能取到首个 ts/key。只有两段都过，源才算"真活"。

并发与风控是第三个坑。 几百个源若在同一时刻全量并发，很容易被上游 CDN 判定为异常流量，导致整批误判。工程上需要按域名维度做并发上限、随机化探测间隔、设置分级超时（列表接口短超时、媒体地址长超时）、失败后指数退避重试，并轮换 UA。这些参数不是拍脑袋定的，而是需要在"探测及时性"和"不打扰上游"之间找平衡。

判定模型上，二元黑白名单是错的。 更合理的是健康度打分：滑动窗口内的成功率、平均首字节延迟、最近一次失败的时间衰减加权，输出一个 0–100 的分数。客户端可以按分数排序而非过滤，挂了一半的源不会直接消失，但会沉底。这是这类项目最有价值的隐性设计。

最后，结果不应由客户端实时回源查询。正确姿势是冷热分离：探测结果落库（SQLite 或 Redis），周期性生成静态 JSON，通过对象存储或 CDN 分发，把探测压力与消费流量彻底解耦。

功能亮点与差异

一个后台，喂三种前端。 同时输出 LibreTV、MoonTVPlus、maccms 三种消费形态，意味着它把"源数据的表示层"抽出来了。对自建用户来说，这意味着换播放器不用重建源列表——这是相比"复制别人 JSON 配置"的质变。

它是活体目录，不是静态导航。 与各类资源站索引站的根本区别在于：索引站给链接，它给状态。这一点决定了它在链路中的位置——它是数据面，不是入口页。

轻量可自托管。 从定位判断，它面向的是个人 NAS / 小站站长场景，单容器 + 持久化卷即可跑起来，不需要 Kafka、ES 这类重型组件。对于"我就想让自己那 50 个源别再挂了"的需求，这个取舍是对的。

应用场景与落地建议

适合：个人自建影视站与播放器的源供给、小规模聚合站的采集层前置校验、给团队内部做采集源质量看板。

需要警惕的几点：

• 别把探测打成攻击。 全量探测间隔建议不低于 30 分钟，失败源单独走 5–10 分钟的快速重试通道，避免持续轰炸同一上游。这既是技术问题也是社区礼仪问题。
• 区分"探测失败"和"源失败"。 探测服务自身网络故障会导致全量源被判死，这是这类系统最危险的单点。必须有探测侧心跳，并在结果中携带"本次探测样本量/异常率"，异常率超阈值时冻结更新而非清空列表。
• 先灰度判定规则。 两段式校验的阈值（超时秒数、m3u8 校验深度）建议先用小样本源对照人工验证，否则容易误杀仍在工作但响应慢的源。
• 输出走缓存。 前端只读静态产物，别让客户端直连探测服务。
• 合规边界。 项目本身只做技术聚合与探测，但采集源的版权属性必须由部署者自行评估，公开分发此类列表存在风险。

综合评价

优点：切中真实痛点且切口精准；架构分层清晰，适配器 + 探测 + 分发三段职责分明；健康度打分优于业界常见的二元判断；多客户端格式适配是差异化最强的设计；部署成本低，符合目标用户的实际运维能力。

不足：探测策略高度依赖经验参数，缺乏自适应能力，源结构变化频繁时误报率会上升；对 maccms 各种魔改变种的兼容需要长期打补丁，这是无解的维护税；单机架构在源规模上千后调度与并发会成为瓶颈，缺少分布式探测能力；生态与文档相对薄，新用户上手仍需读代码。

一句话结论：它不是一个"资源站"，而是一台针对采集源的体检机——价值不在收录多少源，而在能否诚实地告诉你哪些源此刻还活着。对于任何依赖 maccms 采集接口的项目，这一层几乎是必需品。