离线边缘节点首选unless-stopped策略：系统崩溃、断电、OOM后自动恢复，但手动docker stop后不再拉起，兼顾自愈与运维可控；禁用always以防掩盖故障、争抢资源；临时任务用on-failure:3限次重试；须配合本地依赖校验与健康检查。
离线边缘节点没有稳定网络，重启策略选错就容易丢数据、服务起不来。核心是让容器在断电、崩溃、系统重启后能自动恢复，且不因误操作反复拉起。
离线场景下必须禁用 always 策略
离线环境无法依赖中心调度或远程干预，always 会强制重启已手动停掉的容器，比如运维人员为排查问题临时停服，结果系统一重启它又自己跑起来，掩盖真实故障点。
- 除非有本地守护脚本配合做状态校验，否则一律避免使用 always
- 离线节点一旦误配 always，可能引发资源耗尽或配置冲突，尤其当多个容器争抢串口、GPIO 或共享内存时
unless-stopped 是离线节点的默认首选
它兼顾自愈与可控：系统重启、进程崩溃、OOM 杀死后都会自动拉起，但只要执行过 docker stop，就不会再启动——这对现场维护非常友好。
- 适用于长期运行的传感采集、协议转换、本地缓存服务等主干任务
- 搭配
-v挂载主机路径（如/var/sensor/data）可确保重启后数据不丢失 - 注意：若容器因挂载失败（如 USB 设备未插稳）而无法启动，unless-stopped 仍会不断重试，需配合健康检查或启动前校验脚本
用 on-failure 控制临时任务和子服务
不是所有组件都需要“永生”。比如日志压缩、本地数据库备份、固件校验等周期性任务，适合用 on-failure 配合重试次数限制。
- 示例：
--restart on-failure:3表示最多重试 3 次，失败后彻底退出，避免无限循环占用 CPU - 这类任务通常不挂载持久卷，也不需要常驻，设为 on-failure 更符合离线环境的资源节制原则
- 可结合
docker run --rm使用，任务结束即清理容器，减少磁盘碎片
别忽略启动前的本地依赖检查
重启策略再可靠，也救不了启动失败的容器。离线节点常见问题包括设备节点缺失、配置文件权限错误、证书过期、时间不同步等。
- 建议在容器启动命令前加轻量级 shell 校验脚本，例如检查
/dev/ttyUSB0是否存在、/etc/agent/config.yaml是否可读 - Dockerfile 中用
HEALTHCHECK做基础连通性探测（如 ping 本地 MQTT broker），但不要依赖外部域名或 HTTPS 接口 - 对关键服务，可在启动脚本中加入
sleep 2 && timeout 5 nc -z localhost 1883类检测，失败则 exit 1 触发 on-failure 重试
