qBittorrent 的分类应该对应目录，标签应该对应状态；两者混用，自动移动迟早会乱。

\n
qBittorrent 的分类和标签看起来都只是给任务贴名字，但我实际用下来，最怕它们承担同一种含义。分类一会儿表示目录，一会儿表示任务状态；标签一会儿表示来源，一会儿又表示保留周期。规则多了以后，文件到底应该移动到哪里，就只能靠回忆。

我现在的做法是把它们拆开：分类只代表目标目录，标签只代表处理状态。这个约定看起来朴素，却能减少很多后续维护成本。

分类就是目录契约

分类应该直接对应保存路径。例如 linux-iso 指向公开系统镜像目录，open-data 指向公开授权数据集目录，personal-backup 指向我自己的临时备份目录。分类名可以短，但含义必须固定。一个分类只回答一个问题：这个任务完成后应该落到哪里。

这样设置以后，目录权限也好测。每个分类对应的目录都提前创建，再确认容器用户有写入权限。不要等任务完成后才让 qBittorrent 自动创建目录，因为 NAS 上的权限继承、共享设置和容器身份经常不完全一致，临时创建出来的目录可能能写不能删，或者能写入但其他备份任务读不到。

我也会避免让两个分类指向同一个目标目录。短期看省事，长期看会把保留周期、清理规则和人工检查混在一起。如果两个类别最终都要长期保存，也应该先放在各自的 complete 子目录，确认后再由归档规则合并。

标签只表示处理状态

标签更适合表达流程状态，比如 pending-check、checked、to-archive、needs-review。这些标签不决定文件放到哪里，只提醒我下一步该做什么。比如一个公开数据集任务完成后，分类已经决定它在 open-data 目录，标签只说明它有没有校验、是否已经记录说明文件。

状态标签要少。我的经验是，标签超过五六个，页面看起来很细，实际执行时反而没人坚持维护。低维护的规则比精密但没人执行的规则更可靠。每次新增标签前，我都会问一句：它是能触发一个明确动作，还是只是看起来更像管理系统？如果不能触发动作，就不加。

自动移动必须先小样本测试

自动移动不是打开开关就完事。我会先做一组小样本任务：每个分类放一个很小的合法公开文件或自有文件，观察它从 incomplete 到 complete 的路径变化。测试重点有四个：保存路径是否正确、移动后权限是否正确、失败时日志是否清楚、重复任务会不会覆盖已有文件。

尤其要看容器内路径和宿主机路径。Web UI 里显示的是容器视角，NAS 文件管理器看到的是宿主机视角。如果规则里写了 /downloads/complete/linux-iso，我必须知道它对应宿主机的哪个真实目录。后续清理脚本和备份脚本应该使用宿主机路径，而不是把容器路径硬写进去。

避免规则互相覆盖

qBittorrent 里最容易出错的不是没有规则，而是规则太多。默认保存路径、分类保存路径、自动管理模式、标签备注、人工改路径，这些动作叠在一起，最后会出现“我明明设置了分类，文件却去了另一个目录”的情况。

我的处理方式是固定优先级：先看分类路径，再看自动管理，再看手工覆盖。只要某个任务被手工改过路径，就在备注或维护记录里写明原因，不让它混进通用规则。定期检查时，我会列出各分类的目录和任务数量，发现某个分类目录为空但任务很多，就说明规则可能没有按预期生效。

docker compose config
docker inspect qbittorrent --format '{{json .Mounts}}'
find /srv/public-files -maxdepth 3 -type d | sort
du -sh /srv/public-files/*
docker compose logs --tail=120 qbittorrent

我的分类和标签底线

我不会用分类表达“已校验”“待归档”这种状态，也不会用标签表达“保存到哪个目录”。分类对应目录，标签对应状态，这条边界越早定下来，自动移动越不容易出错。

最后还有一个很实际的检查：删除一个测试分类前，先确认没有任务还引用它；改分类路径前，先确认旧目录里的文件已经归档或清理。qBittorrent 的自动移动适合处理稳定规则，不适合频繁试错。规则少、含义清楚、每次改动都有测试任务，才是家庭服务器里最省心的用法。