Transmission 的优势是轻，适合低维护场景；目录、权限和 RPC 入口比功能数量更重要。

\n
我会在两种情况下选择 Transmission：机器性能一般，或者这个下载器只需要处理少量合法公开资料和自有文件任务。它不像复杂管理平台那样提供很多规则，但这正是它适合低维护环境的原因。功能少一点，排障路径也短一点。

Transmission 上线前，我主要看四件事：watch 目录是否清楚，completed 和 incomplete 是否分开，容器用户是否有权限，RPC 入口是否被控制住。只要这几项稳定，它就能安静地当一个轻量任务入口。

watch 目录适合简单投递

Transmission 的 watch 目录很适合低频使用：把任务文件放进去，它自动接收。这个模式的前提是目录来源可信，且文件命名和保留规则清楚。我不会把 watch 目录做成全家随手丢东西的公共入口，否则任务来源一乱，后面就要花时间解释每个文件是谁放进去的。

watch 目录可以单独挂载，例如 /watch。它和下载工作区分开，方便清理，也能避免误把未处理任务跟已完成文件混在一起。投递后如果没有被识别，先看目录权限和日志，不要急着重建容器。

completed 和 incomplete 必须拆开

Transmission 配置里我会明确未完成目录和完成目录。未完成文件放 incomplete，完成后进入 completed，再由人工或后续脚本进入长期归档。这个分层和 qBittorrent 的思路一样：任务状态不能靠猜，目录本身就应该表达状态。

低维护不是不维护。completed 目录需要定期看占用，incomplete 目录需要确认没有长期失败任务。小机器上磁盘空间更紧张，一个失败任务留在 incomplete 很久，可能比速度慢更麻烦。

权限问题要在第一天解决

Transmission 容器通常会通过 PUID、PGID 或镜像默认用户写文件。NAS 目录如果是共享目录，权限继承可能和普通 Linux 目录不一样。我的做法是先建目录，再用同一个用户身份做写入测试，确认 watch、incomplete、completed 三个目录都能读写。

有些问题看起来像 Transmission 没响应，实际是它无法写状态文件或无法移动完成文件。页面能打开，只说明 RPC 还活着；文件能按预期落盘，才说明挂载和权限真的可用。

RPC 入口要少而稳

Transmission 的 Web/RPC 入口默认很方便，但也不能随意开放。它至少要有强密码和访问范围限制，最好只在局域网或受控入口后面使用。RPC 入口一旦开放，就能操作任务和路径，不应该靠“端口不常见”来获得安全感。

我也会限制并发和速度。Transmission 很轻，但任务跑满时仍然会产生连续写盘、校验和网络占用。低配 NAS 上，下载器应该给数据库、照片服务、文件同步和备份任务让路。稳定地慢一点，比让整机响应变差更好。

适合它的场景

Transmission 适合固定、少量、规则简单的任务。比如定期获取 Linux ISO、同步开源项目发布文件、处理个人有权保存的资料包。它不适合承载复杂分类、复杂状态流和大量自动归档规则。如果需求已经变成多分类、多标签、多阶段审核，那就该重新评估工具，而不是把 Transmission 配到越来越绕。

低维护也意味着巡检要固定。我会定期看 completed 是否有长期未处理文件，incomplete 是否有卡住任务，watch 目录是否残留已经投递过的任务文件。Transmission 的页面不需要天天打开，但目录占用和日志要能说明它最近确实在按预期工作。

我常用的检查命令很少：

docker compose config
docker compose ps
curl -I http://127.0.0.1:9091
docker inspect transmission --format '{{json .Mounts}}'
docker compose logs --tail=120 transmission
du -sh /srv/public-files/*

这些命令能覆盖配置展开、容器状态、RPC 入口、挂载路径、应用日志和磁盘占用。Transmission 的维护不需要写得很复杂，关键是别让简单工具承担复杂流程。

我的结论是：如果你想要一个低维护、低资源占用、规则清楚的轻量下载器，Transmission 很合适。前提是把 watch、completed、incomplete、权限和 RPC 入口从第一天就规划好。它不靠复杂功能取胜，靠的是少出问题、容易恢复、看得懂。