--restart=unless-stopped是硬性要求，不加则NAS重启后容器彻底消失、脚本失联；必须显式指定，禁用always（掩盖启动失败），且需配合-d、-v与-w严格对齐路径。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
--restart=unless-stopped 是硬性要求，不加它就不是自动化，只是临时能跑。群晖NAS重启、DSM升级、断电恢复后，没配这个参数的容器直接消失，脚本彻底失联——这不是“偶尔失效”，而是“一断就死”。
必须用 --restart=unless-stopped 启动容器
常见错误是只写 docker run -d，甚至漏掉 --restart 参数：
• docker run -d python:3.11-slim python job.py → NAS重启后容器彻底消失
• 正确写法必须显式指定 --restart=unless-stopped，且不能用 always（会掩盖启动失败）
• 若用 docker-compose.yml，对应字段是 restart: unless-stopped
• 验证方式：docker inspect mytask | grep -i restart，输出必须含 "unless-stopped"
别用 -it，也别靠 docker exec -it 跑脚本
-it 会绑定终端 stdin/stdout，SSH断开或网页终端关闭，容器立刻退出；docker exec -it 在DSM任务计划等非交互环境里会卡住，2026年9月仍无可靠 workaround：
• 启动时去掉 -it，只留 -d
• 定时任务交给容器内守护进程，比如 supercronic（轻量、无依赖、支持标准 crontab 语法）
• 简单轮询可用 while true; do python job.py; sleep 3600; done || true，但必须加 || true 防止某次异常退出导致整个循环终止
• DSM 的“用户定义脚本”只能作为触发器（例如发 docker kill -s SIGUSR1 mytask），不能直接调 python job.py
-v 和 -w 必须配对，否则 open("config.json") 直接报错
脚本里用相对路径读配置，却忘了容器内路径和宿主机不一致，是最常见的 FileNotFoundError 根源：
• -v /volume1/docker/mytask:/app 把 NAS 上目录挂进容器
• -w /app 显式设工作目录，让 python job.py 的当前路径就是 /app
• 所有文件（job.py、config.json、logs/、output/）都放在这同一个挂载点下
• 别在容器里写 cd /volume1/scripts && python x.py —— 容器根本没有 /volume1/scripts 这个路径
• 挂载后检查：docker exec mytask ls -l /app，确认能看到你的脚本和配置文件
镜像选 python:3.11-slim，别碰 latest 或模糊标签
python:3 这类模糊标签会随 Docker Hub 自动更新，2026年5月以来已出现多起因 zoneinfo 或 httpx 版本突变导致脚本崩溃的案例；latest 更被官方标记为“不推荐用于生产”：
• python:3.11-slim 固定小版本，基础层更小、启动更快、攻击面更少
• --slim 版本不含 gcc、make 等编译工具，但绝大多数纯 Python 脚本（requests、schedule、feedparser）完全够用
• 若真需要编译依赖（如 pydantic-core），改用 python:3.11-bookworm 并在 RUN 阶段装 build-essential
-v 只负责把文件“放进去”，-w 才决定脚本“从哪开始找”。漏掉 -w，哪怕文件全在容器里，open("config.json") 依然报错——这个细节在调试阶段几乎无法复现，只会在NAS重启后突然失效。 
