必须用--restart=unless-stopped，否则nas重启后容器彻底失联；禁用docker run -it，需后台常驻、挂载目录与工作路径匹配、用supercronic等容器内守护进程实现自动化。
docker run 启动的容器不加 --restart=unless-stopped 就算脚本跑通了，NAS重启后也会彻底失联——这不是“能跑”，而是“一断就死”。必须用带自动恢复策略的长期运行模式，否则自动化就名存实亡。
为什么不能用 docker run -it 交互式启动
这种命令只适合调试，一旦 SSH 断开或终端关闭，容器立即退出。群晖上没人在旁边守着终端，脚本必须脱离交互环境自维持：
- -it 会绑定 stdin/stdout，无法后台常驻
- 没有 --restart 策略，NAS 重装 DSM、意外断电、系统升级后容器全消失
- 日志无法持久化，崩溃后查不到 Traceback
- 无法配合 DSM 任务计划做状态检查或手动触发
python:3.11-slim 镜像比 python:3 更稳妥
别图省事用模糊标签（如 python:3），它会随 Docker Hub 更新悄悄变版本，某天突然因 zoneinfo 或 httpx 兼容问题挂掉：
- python:3.11-slim 固定小版本，基础层更小、启动更快、攻击面更少
- -slim 版本不含 gcc、make 等编译工具，但绝大多数纯 Python 脚本（requests、schedule、feedparser）完全够用
- 若真需要编译依赖（如 pydantic-core），改用 python:3.11-bookworm 并在 RUN 阶段装 build-essential
- 避免用 latest：2026 年 5 月起官方已标记其为“不推荐用于生产”
挂载目录和工作路径必须匹配，否则 open("config.json") 直接报错
常见错误是脚本里写相对路径，但容器内工作目录不对，或宿主机文件根本没挂进去：
- 用 -v /volume1/docker/mytask:/app 把 NAS 上的目录挂进容器
- 必须配 -w /app，让 python script.py 的当前目录就是挂载点
- 所有配置文件（config.json）、日志（logs/）、下载产出（output/）都放在这个挂载目录下
- 别信“我脚本放 /volume1/scripts，然后 cd /volume1/scripts && python x.py”——容器里根本没有这个路径
定时任务别靠 DSM 任务计划直接调 python3，用容器内守护进程
DSM 的“用户定义脚本”任务本质是每分钟拉一次 shell，容易和容器进程冲突，且无法感知 Python 异常退出：
- 在容器里用 supercronic（轻量 cron 替代）：一行配置就能按 crontab 格式跑脚本
- 或直接在启动命令里用 while true; do python job.py; sleep 3600; done 做简单轮询（适合低频任务）
- 禁止在容器外写“docker exec -it mytask python job.py”——-it 会导致非交互环境下卡死
- 所有日志输出到 stdout，用 docker logs -f mytask 实时看，别往容器里写文件再手动去翻
真正的难点不在“怎么跑起来”，而在于“怎么让它自己活下来”。挂载路径写错、镜像标签漂移、重启策略漏设——这三处出问题，脚本可能稳定运行三个月，然后某次 DSM 升级后悄无声息地停摆，连告警都没有。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
