2026 年 7 月 19 日，Hacker News 上一个标题为”Better and Cheaper Than IPTV”的帖子拿到了 219 分。链向的是一个 GitHub 仓库——stupside/castor，612 颗星，61 次提交，MIT 协议开源。
六字标题把姿态拉得很高。但在读完整个 README 和 54 条评论之后，笔者的判断是：Castor 不是一个 IPTV 的”平替”，也不是某种 P2P 流媒体协议。它是一个终端工具。一个用 Go 写的 CLI，做的事情很明确——从任意网页里找到视频流，抽出来，转码，投屏到你的电视上。
这个定位比”Better and Cheaper Than IPTV”本身更有趣。因为它暴露了两个正在同时发生的事情：一部分用户已经厌倦了每月付 15 到 20 美元买一个 IPTV 订阅，而另一部分开发者正在用开源工具把”看电视”这件事拆解成一组可组合的原子操作。抓流是一个工具，转码是一个工具，投屏是一个工具——你不需要等某个公司把这三个功能打包成一个产品卖给你。
Castor 到底做了什么
先说明白这个工具在技术上的工作流程。Castor 的作者在 README 里写得很直白：“我建这个是因为我没法把笔记本上的网页视频投到电视上——没有 Chromecast，没有 AirPlay。“这是一个典型的”痒处驱动”项目：不是宏大愿景，是具体到一张沙发的使用场景。
Castor 的工作分成四步。第一步，你给它一个网页地址或者一个 IMDB/TMDB 电影 ID，它启动一个 headless Chrome 实例，随机化浏览器指纹，注入反检测脚本，通过 Chrome DevTools Protocol 监听所有网络请求，直到抓到视频流的 URL。第二步，用 ffmpeg 把抓到的流转码成电视能解码的格式。第三步，需要字幕的话，它调用 whisper.cpp 做实时语音识别，把字幕烧进视频画面。第四步，通过 DLNA/UPnP 或 Chromecast 协议把流推送到局域网内的电视上。
这四步里最”脏”的是第一步。Castor 的流提取依赖一套动作管线——点一下页面、跳进最大的 iframe、如果遇到 Cloudflare Turnstile 就自动点击、再点一下作为最后手段。作者在文档里坦率承认：这招对大多数流媒体站点有效，但打不过复杂的反爬系统。
HN 上有用户直接表达了不满。inigyou 评论道：“这种让机器人跑 headless 浏览器的情况本身就很荒唐。Cloudflare 你挡不住机器人，只是在浪费双方的时间。“另一个用户 Lwrless 从指纹对抗的角度做了技术评估：Castor 目前只 patch 了 navigator、Audio API 和 Canvas API，属于比较基础的伪装，“大概率还是会被检测出来。”
这些批评指向一个现实：Castor 的提取层活在一种持续的猫鼠游戏中。今天能用的流媒体站点，明天可能就加了一层新的防护。这个工具需要持续维护——窗口开多大，取决于反爬和反反爬之间的攻防节奏。
图：Castor 的终端交互界面，通过 TMDB API 浏览和搜索电影标题，直接在终端中完成选片和投屏。来源：stupside/castor GitHub
”比 IPTV 更便宜”的账怎么算
既然 HN 标题把”便宜”作为卖点，我们来算一下这个账。
一个典型的付费 IPTV 服务，月费 15 到 20 美元，提供的是”打包好的频道列表 + 稳定的流媒体源 + 可用的客户端界面”。用户花钱买的是内容加上一个”不用折腾”的体验。打开 App，切频道，看电视——整个流程的认知成本接近于零。
Castor 的方案是反过来的。它的物质成本确实更低：工具本身是免费的，你需要的只是一台能跑 Chrome 和 ffmpeg 的电脑，以及一台支持 DLNA 的电视——基本上过去十年里任何一台智能电视都满足这个条件。Docker 镜像 ghcr.io/stupside/castor 封装了所有依赖，一条命令就能拉起。
但这里的隐性成本是维护成本。你需要自己维护 config.yaml 里的流媒体源列表。这些源随时可能离线、换域名、加防护，你需要持续关注和更新。你还需要接受一个事实：Castor 不保证任何一个源在明天还能正常工作。
换句话说，IPTV 卖的是可靠性，Castor 卖的是自主权。两种产品解决的不是同一个问题。选择哪一个，取决于你更愿意把时间花在”调试一个反爬工具”还是”付月费然后忘记它的存在”。
HN 上有一个值得注意的替代方案——用户 dtagames 贴出了自己做的 TV Explorer（tvexplorer.live），直接利用 GitHub 上一个公开维护的、包含超过 10,000 个免费频道的 HLS 流列表，在浏览器里播放，不做任何提取和转码。用户 ssl-3 对 TV Explorer 的评价是：“这是我自模拟 NTSC 时代以来，最快、最灵敏的’看电视’体验。切频道像当年从 11 台切到 13 台一样快。”
这个对比点出了一件事：当流本身是公开可得的 HLS 地址时，“提取”这一步根本不需要。Castor 的 headless Chrome 管线本质上是在解决一个本不该存在的问题——网站把视频流藏在一层层 iframe 和反爬脚本后面，于是你不得不雇一个机器人去帮你翻这些障碍。
社区讨论的三种声音
54 条 HN 评论大致可以分成三类。
第一类是”这个工具到底是不是为盗版而做的”。用户 Croftwarden 直说：“通常盗版软件会保持一点可否认性，但这个直接建议你用它看本周刚上映的 2.5 亿美元大片。“作者随后更新了 README，加了一段免责声明——Castor 本身不托管任何视频，不附带任何内容，config.yaml 里的源只是示例，用户应当只投屏自己有权限访问的内容。
第二类是技术讨论，主要围绕 headless 浏览器检测、反爬对抗和流提取的可靠性。这一线的讨论质量较高，但也让人看清一件事：Castor 的核心竞争力是它把提取、转码、字幕、投屏串成了一条端到端的管线，并且做到了”一条命令从 ID 到电视画面”的用户体验。
第三类是”有没有更简单的方法”。除了 TV Explorer，还有用户问能不能直接在 VLC 里用、能不能做成 Jellyfin 插件、能不能支持 Roku 设备。这些提问反映了一个更广泛的需求：用户想要的是一个能把”互联网上的视频内容”和”客厅里的电视屏幕”无缝连接起来的通用管道，而不是一个需要配置 YAML 文件和调试反爬策略的命令行工具。
图：Castor 扫描局域网中的 DLNA/UPnP 设备，让用户选择投屏目标。来源：stupside/castor GitHub
流媒体工具的”拆解”趋势
如果我们把视线从 Castor 这一个工具上拉远，能看到一个更大的趋势：流媒体观看正在从”一体化服务”向”可组合工具链”迁移。
十年前，看电视的路径只有一条：付费订阅某个服务商的套餐，用服务商提供的机顶盒或 App，看服务商买了版权的内容。价值链上的每个环节——内容采购、流编码、CDN 分发、客户端播放——都在同一个商业实体内部完成。
现在这条链正在被拆解。Castor 拆的是”流获取”和”投屏播放”这两个环节。IP-TV-org 维护的公开 M3U 播放列表拆的是”频道聚合”。TV Explorer 拆的是”频道发现和播放界面”。Whisper.cpp 拆的是”实时字幕生成”。ffmpeg 拆的是”跨格式转码”。
这些工具各自解决一个原子问题，组合起来可以拼出一个完全绕过商业 IPTV 服务的看电视方案。这不是一个产品，是一个 LEGO 套件。
但 LEGO 套件有一个固有的问题：你需要自己动手拼。而大多数人不想自己动手拼。这就是为什么付费 IPTV 服务到今天仍然有市场——它们卖的本质上不是内容，是”不用拼”。
回到那个标题
HN 帖子标题说”Better and Cheaper Than IPTV”。读完所有材料之后，笔者倾向于认为这个标题是一种”争议性表述”而非事实陈述。
便宜，在”工具费为零”的意义上成立。但在”时间成本”和”维护成本”的意义上不成立。更好，在”你完全控制自己的工具链”的意义上有讨论空间。但在”打开就能看”的意义上明显不如。
Castor 真正的价值不在它想替代 IPTV 的那个叙事里。它的价值在于它展示了一种可能性：当流媒体基础设施（Chrome DevTools Protocol、ffmpeg、DLNA、whisper.cpp）都已经成熟到可以作为积木被任意组合时，一个单枪匹马的开发者用 61 次提交就能造出一个功能完整的看电视工具。612 颗星不是对它”击败了 IPTV”的投票，是对这种”工具主权”的投票。
用户在评论区的实际行为也印证了这一点——讨论很快从 Castor 本身转向了 TV Explorer、转向了公开 M3U 源列表、转向了 Jellyfin 插件和 VLC 集成。人们想要的是一个更开放的、让不同工具可以互操作的流媒体生态。Castor 是这个方向上的一块积木，离终点站还很远。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接
- Castor GitHub 仓库（stupside/castor，MIT 协议开源）
- HN 讨论：Better and Cheaper Than IPTV (219 分, 54 条评论)
- TV Explorer：公开 M3U 源索引工具
