Container Station 适合轻量自托管，但容器重建、环境变量和挂载目录经常才是最容易出问题的地方。
Docker 的价值不在于“装得更多”
在 NAS 上运行 Docker，最吸引人的地方是可以把服务隔离开。
Plex、MoviePilot、网络工具、列表服务和其他自托管应用不必全部依赖 NAS 原生套件。容器让部署、迁移、更新和清理更可控，但前提是配置本身要可读、可备份。
我现在更看重三个东西：
- 数据目录是否清楚
- 环境变量是否可追踪
- 容器重建后是否能恢复原状态
容器数据不要混在一起
每个容器应该有明确的数据位置。
例如：
/share/Container/
├── moviepilot/
│ ├── config/
│ ├── cache/
│ └── logs/
├── plex/
│ ├── config/
│ └── transcode/
├── mihomo/
│ └── config/
└── openlist/
└── data/这样做有几个好处：
- 删除容器不等于删除配置
- 迁移到新 NAS 时可以只迁走对应目录
- 备份可以按服务粒度执行
- 出问题时更容易判断是容器问题还是数据问题
我尽量避免把重要配置直接留在容器内部。容器本身应该是可随时删除并重新创建的，真正需要留下的是挂载到宿主机的数据。
MoviePilot 重建前要检查环境变量
我遇到过一个很典型的问题：在 Container Station 中重新创建 MoviePilot 容器时，某个环境变量已经存在，界面又重复添加，结果导致配置提交失败或出现异常提示。
这类问题说明，图形界面虽然方便，但仍然要把 Docker 当作一份明确的配置，而不是不断点按钮试出来的状态。
每次重建容器前，我会检查：
- 镜像名称与标签
- 容器名称
- 端口映射
- 卷挂载路径
- 环境变量
- 网络模式
- 重启策略特别是环境变量：
MOVIEPILOT_AUTO_UPDATE这类开关必须只保留一条，并确认值与实际预期一致。不要在“已有变量”和“新增变量”两处同时填写同一个键。
自动更新不一定是好事
很多容器提供自动更新选项，但对家庭媒体服务来说，我更倾向于手动控制更新。
原因很简单：
- 新版可能修改配置格式
- 插件、接口或站点规则可能突然失效
- 媒体整理任务不适合在无人看管时被打断
- NAS 性能有限，更新和数据库迁移可能影响其他服务
我更习惯这样做：
- 先看更新说明
- 备份配置目录
- 拉取新镜像
- 重建或更新容器
- 检查日志
- 验证核心流程，例如下载、整理、刮削和推送
Docker 的可重复性，不应该被“自动升级一切”破坏。
Plex 的重点是直连播放
在性能有限的 NAS 上，Plex 最怕的通常不是媒体库大，而是实时转码。
我会尽量让播放设备支持原始视频和音频格式，让 Plex 以 Direct Play 为主。这样 NAS 更多是在提供文件和元数据，而不是持续做视频编码。
对于家庭媒体库，编码格式规划往往比升级 CPU 更有效：
- 尽量使用客户端兼容的编码
- 字幕优先考虑不会触发烧录的格式
- 避免高码率文件在弱网络环境下频繁转码
- 在外网播放前先测试实际客户端能力
保持一个可恢复的配置文件
即使主要使用 Container Station 图形界面，我也会把服务参数同步保存为文本记录，最好是 Compose 格式。
至少记录：
services:
app:
image: example/app:latest
container_name: example-app
restart: unless-stopped
volumes:
- /share/Container/example/config:/config
environment:
- TZ=Asia/Singapore它不一定马上用于命令行部署，但当 Container Station 配置丢失、NAS 迁移或需要排查问题时，这份记录非常有价值。
最后
NAS 上 Docker 的理想状态不是“容器很多”，而是任何一个容器都能被你解释清楚：
- 它做什么
- 数据在哪里
- 如何更新
- 出错时看哪里
- 删除后能否恢复
这才是自托管服务长期可用的基础。