项目详情
LunaTV
自部署影视聚合播放器——fork 数几乎追平 star 数的现象级项目
GitHub 地址
CC BY-NC-SA（desc）· 仓库标记无识别许可
10.3k Stars / 9.1k Forks
Next.js 14 · Docker
原 MoonTV
更新于 2026-09-09
← 返回汇总
项目速览
一句话定位
自己的影视站，一键部署
Next.js 14 全栈影视聚合播放器：站长填入若干「资源站」（苹果 CMS V10 协议的采集站 API），即得一个多源聚合搜索、在线播放、收藏与播放记录多端同步、PWA 可安装的私人 Netflix。空壳设计——项目本身无任何内置源，播放源完全由部署者自行收集。3 年不到 10.3k stars、9.1k forks（fork 接近 star，自部署传播的极端案例）。技术上是现代前端全栈的规整样本；争议上，它是「工具中立」设计与「实质用途」之间距离最远的项目之一。
项目速览
核心数据
数据来源：GitHub API，采集于 2026-09-09。MoonTechLab org（原 MoonTV 项目更名延续）；GitHub 许可识别为 NOASSERTION（仓库描述写 CC BY-NC-SA，README 徽章写 MIT——自相矛盾）。
为什么存在
需求真实，姿态防御
中文互联网的影视消费有个结构性真空：版权分散、平台割裂、会员费叠加。「一个搜索框搜全部片源」的需求真实且巨大——fork ≈ star 的 88% 就是证据：人们不是收藏研究，是直接拿去自己部署。
- 空壳哲学：项目零内置源，README 反复强调「部署后为空壳项目，无内置播放源和直播源，需自行收集」——把内容责任推给部署者
- 站长模式：一人部署、家人朋友共用，或小圈子开放注册——自建站的经典形态
密集的防御性动作
- 禁止在中国大陆社交平台宣传（B站/小红书/公众号/抖音/头条点名）
- 不授权任何「科技周刊/月刊」收录
- 仓库描述声明 CC BY-NC-SA、禁止商业化
- 从 MoonTV 更名 LunaTV 迁移 org
每一招都是这类项目面对现实压力的标准防御——作者显然清楚项目处在什么位置。
技术架构
现代全栈的规整样本
前端/播放
聚合/存储（依赖站长供源）
部署体验
把部署摩擦压到最低
Zeabur 一键
模板按钮自动拉起 LunaTV + Kvrocks 双服务，配好网络与持久化卷——非技术用户的最短路径。
Docker Compose
ghcr.io 镜像 + 三种存储后端 compose 示例全给齐，watchtower 自动更新也有现成方案。
配置即订阅
采集站配置文件 base58 编码后挂 http 即为「订阅链接」——站长圈的配置分发协议，生态习惯。
USERNAME=admin PASSWORD=xxx NEXT_PUBLIC_STORAGE_TYPE=kvrocks \
# 三个环境变量 + 一个采集站配置文件 = 完整影视站
功能细节也照顾周到：详情页剧集列表/演员/简介、豆瓣自定义分类（华语/美剧/豆瓣高分等官方支持词表）、AndroidTV 使用指引、管理员后台。
生命周期
改名、放缓与这类项目的宿命
- MoonTV → LunaTV：更名 + 迁移 org——原项目形态在传播压力下的标准生存动作，与 LibreTV 等同类项目共享同一条命运曲线
- 更新放缓：2026-02~05 密集发版（虚拟滚动优化、失效豆瓣源清理）后，5 月底至今 3 个多月无提交
- 版本号玩梗：v100.1.x 的命名跳脱常规——社区分发版本混乱的侧面注脚
- 维护集中度：3+ 贡献者、10 个 open issue——项目实质是单人驱动
- 可预期的路径：这类项目的终局通常是三类——隐匿维护、被施压下架（社区 fork 接力）、或自然停更；fork 9k 意味着代码与部署知识早已广泛扩散，repo 本身不再是非要害节点
合规深水区
「工具中立」离「实质用途」最远的项目
- 实质要说透：采集站（苹果 CMS V10 资源站）的内容几乎全部是未授权影视。聚合播放器的实际用途与盗版观看高度重合——空壳设计是法律防火墙，不改变生态位
- 部署者的风险是自己的：自部署供个人/小圈子使用与对外运营（尤其收费）之间隔着数量级的法律差异；作者禁商业化条款把这个边界写在了协议里
- 许可证自相矛盾：仓库描述 CC BY-NC-SA vs README 徽章 MIT vs GitHub 识别 NOASSERTION——使用者处于许可不确定状态，任何衍生都该默认最严格条款（NC + 相同方式共享 + 保留出处）
- 本站收录立场：作为技术样本收录（Next.js 全栈/多存储抽象/部署体验设计），不构成使用建议；观看盗版内容在多数司法辖区有真实法律风险
潜力评估
打分
| 维度 | 评分 | 依据 |
|---|
| 工程完成度 | | Next.js 14 全栈规整，多存储抽象/PWA/虚拟滚动——无炫技但扎实 |
| 部署体验 | | 一键模板/compose 三示例/订阅分发——摩擦压到极限 |
| 需求验证 | | fork≈star 的自部署传播是最硬的需求证据 |
| 合规清晰度 | | 实质用途即风险源；许可证自相矛盾加重不确定 |
| 可持续性 | | 3+ 月未更、单维护者、品类宿命循环 |
综合 6.5/10。作为「中文 Web 全栈 + 部署体验设计」的技术样本值得一看，需求真实到罕见；但合规风险是结构性的、维护已放缓——收藏研究价值高于部署使用价值。
最终裁决
适合谁，不适合谁
看
- 学 Next.js 14 App Router 全栈组织（路由/存储抽象/PWA 落地）
- 研究多存储后端抽象层的设计（Kvrocks/Redis/Upstash 一套接口）
- 观察「防御性开源」现象：空壳设计、许可话术、更名迁移的完整案例
别碰
- 对外运营、收费、公开传播——法律风险数量级放大，且被协议明文禁止
- 当作有长期维护预期的依赖项目（3+ 月未更 + 品类宿命）
- 企业/生产环境任何场景