Watcharr：自托管观看清单，用 Go 与 Svelte 搭建，但游戏支持需要额外配置
开源、可自托管的观看列表，包含您的所有内容（电影、电视剧、动漫、游戏），具有用户身份验证、现代、干净的用户界面和非常简单的设置。
秒懂
- 它是什么？
- Watcharr 是一个用 Go 和 Svelte 编写的自托管观看清单，支持电影、剧集、动漫和游戏。它部署简单，界面现代，但游戏追踪依赖外部配置，且演示实例时好时坏。
- 适合谁用？
- Watcharr 适合已经熟悉 Docker 和自托管流程的个人用户，尤其是那些想要一个界面现代、部署快速的观看清单，并且不介意偶尔查看 GitHub issue 的人。不适合需要稳定演示或完整游戏库管理的人，因为游戏支持需要额外配置 IGDB，且演示服务器可能离线。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 3 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，给谁用
Watcharr 解决的是自托管用户的一个具体痛点：没有一个简单、统一的地方记录你看过、正在看或计划看的电影、剧集和动漫。商业服务如 Trakt 或 IMDb 需要注册账号，数据不在你手里。Watcharr 让你自己托管，数据完全由你控制。它面向的是那些已经运行着 NAS 或家用服务器的人，他们愿意花几分钟部署一个容器，换取一个私有的观看记录。游戏支持是附加功能，但需要额外配置，不是开箱即用。README 里说它是“easily self-hosted content watched list”，语气轻松，但实际部署门槛取决于你对 Docker 的熟悉程度。
架构与数据流：Go 后端加 Svelte 前端
Watcharr 的代码结构很清晰：后端用 Go，前端用 SvelteKit。Go 负责 API 和用户认证，Svelte 负责界面。数据流大致是这样的：用户在前端搜索内容，前端调用后端的 API，后端从外部元数据源（如 TMDB）拉取信息，然后存储到自己的数据库。游戏数据则通过 IGDB 获取，但需要你在配置里提供 API 密钥。整个应用以 Docker 镜像分发，镜像名是 ghcr.io/sbondco/watcharr。README 提到一个 docker-compose.yml 文件，说明官方推荐用 Compose 部署。这种前后端分离的设计让界面响应快，但部署时你需要同时处理两个部分，虽然 Docker 已经封装好了。
部署：一条命令还是看文档
部署 Watcharr 有两种方式。第一种是直接使用仓库根目录的 docker-compose.yml 文件，适合熟悉 Docker 的人。第二种是阅读官方文档，地址是 watcharr.app/docs/category/installation。文档会告诉你如何配置环境变量，比如数据库连接、端口映射等。我没有实际运行过，但根据仓库布局，你至少需要设置一个数据目录来持久化存储。如果你不想读文档，可以试着复制 docker-compose.yml 然后运行 docker compose up -d。不过，游戏支持需要额外步骤，文档里专门有一节叫 game-support-igdb，说明你需要去 IGDB 申请 API 密钥，然后在配置里填入。这个额外配置是很多人会忽略的点。
游戏支持：功能存在，但门槛高
Watcharr 的核心是电影和剧集，游戏是“with some extra configuration”才能用的功能。这意味着默认安装下，你只能管理影视内容。要启用游戏，你得去 IGDB 注册开发者账号，获取客户端 ID 和密钥，然后按照文档配置。这个流程对非技术用户来说是个障碍。而且，IGDB 是 Twitch 旗下的服务，它的 API 有速率限制，如果你有大量游戏要添加，可能会遇到请求失败。相比之下，影视元数据可能来自 TMDB，这个接口通常更宽松。所以，如果你主要想管理游戏库，Watcharr 不是最省事的选择，你可能需要看看专门为游戏设计的工具，比如 GOG Galaxy 的替代品或自定义数据库。
社区工具与扩展：Kodi 插件是亮点
Watcharr 有一个社区工具列表，目前只列出了一个 Kodi 插件，由用户 airdogvan 开发。这个插件可以自动追踪你在 Kodi 上观看的剧集和电影，然后同步到 Watcharr。这对使用 Kodi 作为媒体中心的用户来说很实用，省去了手动标记的麻烦。但 README 也明确说，作者不对这些第三方工具提供保证，也不负责维护。这意味着如果插件出了问题，你得去插件的仓库提 issue，而不是 Watcharr 的仓库。这种依赖外部维护的模式有风险，因为如果插件作者停止维护，你的自动化就会中断。在决定依赖这个插件之前，先检查它的更新频率和 issue 处理情况。
演示实例与可靠性：一个诚实的警告
README 里有一个值得注意的细节：演示实例 beta.watcharr.app 可能经常离线。作者在 2026 年 8 月 23 日提到服务器出了问题，需要几天修复。他还说演示实例是“worst-case scenario for speed”，意思是速度最慢的情况，自托管会快很多。这透露了两点：第一，作者对性能有自知之明；第二，演示服务器的稳定性不是优先事项。如果你打算先试玩一下再决定是否部署，可能会遇到打不开的情况。但作者建议你自己部署一个实例来体验，声称“less than a minute”。这个说法可能有点乐观，因为你需要拉取 Docker 镜像和初始化数据库。不过，考虑到镜像应该不大，一分钟内跑起来是可能的。
维护与升级成本：GPL-3.0 下的自主责任
Watcharr 使用 GPL-3.0 许可证，这意味着你可以自由使用、修改和分发，但如果你分发修改版本，必须开源。对于个人自托管用户来说，这个许可证几乎没有限制。维护成本方面，项目最近更新频繁，v4.2.1 在 2026 年 8 月 4 日发布，距离 v4.2.0 只有一天。这种快速迭代说明项目活跃，但也意味着你需要经常更新镜像来获得修复和新功能。升级时，你需要检查数据库迁移是否兼容，虽然文档可能没有明确说明，但通常这类项目会提供迁移脚本。如果你不更新，可能会错过安全修复。另外，项目默认分支是 dev，意味着开发版本可能不稳定，建议使用发布标签来部署。
编辑结论
Watcharr 适合已经熟悉 Docker 和自托管流程的个人用户，尤其是那些想要一个界面现代、部署快速的观看清单，并且不介意偶尔查看 GitHub issue 的人。不适合需要稳定演示或完整游戏库管理的人，因为游戏支持需要额外配置 IGDB，且演示服务器可能离线。在采用前，先确认你的内容来源是否满足需求，比如是否接受从 TMDB 拉取元数据，以及是否愿意为游戏功能配置外部 API。最后，检查 v4.2.1 的发布说明，确认你需要的功能（如用户认证的细节）是否已实现。
社区笔记