Docker Desktop 不提供图形界面配置 restart 策略，该策略完全由 docker-compose.yml 中 service 下级的 restart 字段决定，必须与 image 等字段同级缩进，否则被静默忽略；支持 no、on-failure:3、always、unless-stopped 四种策略，行为差异显著，且需配合 healthcheck 防止重启风暴。
直接说结论：Docker Desktop 本身不提供图形界面配置 restart 策略的功能，所有 restart 行为完全由 docker-compose.yml 文件中的 restart 字段决定，和是否用 Docker Desktop 启动无关。
restart 字段必须写在 service 下级，且缩进对齐
很多人在 Docker Desktop 里点“Start”后发现容器没自动重启，不是 Desktop 的问题，而是 YAML 写错了位置。Docker Compose 解析时会静默忽略错误缩进的 restart，根本不会报错。
-
restart必须和image、ports、environment处在同一缩进层级（通常是两个空格或四个空格，但必须统一） - 不能顶格写（会被当成 services 的同级字段，无效）
- 不能缩进比
image多一级（比如写成子字段），也不能塞进deploy:或healthcheck:块里 - Docker Desktop 的“Restart”按钮只是手动触发
docker-compose restart，和自动重启策略无关
四种 restart 策略的行为差异直接影响生产稳定性
选错策略在 Docker Desktop 里看起来一样能跑，但宿主机重启或容器崩溃后表现天差地别。
-
no：默认值，退出就停，适合调试容器或一次性脚本 -
on-failure:3：只在非零退出码时重试，最多 3 次；适合批处理任务，防无限崩溃循环 -
always：任何退出都拉起，包括你手动docker-compose stop后 Docker 守护进程重启——它还会起来 -
unless-stopped：最常用，行为同always，但只要你执行过docker-compose stop，之后 Docker 重启就不会再自动拉起，方便计划维护
光设 restart 不够，依赖服务未就绪会引发重启风暴
在 Docker Desktop 里看到 Web 容器反复 restarting？大概率是它连不上数据库，每次启动就崩，然后按 on-failure 或 always 立刻重试，形成死循环。
-
depends_on只等容器创建成功，不等 PostgreSQL 启动完、不等 Redis 加载完 RDB - 必须配合
healthcheck+condition: service_healthy才真正可靠 - 例如给 db 加
healthcheck，web 的depends_on改成：depends_on: db: condition: service_healthy - 否则
restart不是高可用，是“高崩溃频率”
最容易被忽略的一点：Docker Desktop 默认启用 Docker Engine 自动启动，这意味着 unless-stopped 和 always 在宿主机开机后真会自动运行——但如果你本地开发时频繁改配置，又忘了 docker-compose down，旧容器残留状态可能干扰新启动逻辑。
