嘿，这个问题我之前折腾Swarm的时候也碰到过，当时懵了好一阵，后来翻了Docker的文档和社区讨论才搞明白，我来给你拆解下：

首先，镜像到底是什么？ #

你提到的这些标签的镜像，其实大多是Docker Swarm部署服务时生成的临时镜像，结合你用官方镜像部署Stack的场景，这是最主要的原因。

Swarm在调度和运行服务的时候，不会直接用你指定的带标签镜像（比如mysql:8.0）启动容器，而是会基于这个基础镜像做一些额外的内部处理，生成一个临时镜像来运行容器：

• 注入Swarm服务的元数据、网络配置
• 处理环境变量的注入层
• 为卷挂载、服务约束等添加临时适配层

这些额外操作会给临时镜像增加新的镜像层，所以它的总大小会比你指定的基础带标签镜像要大。

为什么你的镜像大小差这么多？ #

看你贴的镜像数据：

mysql <none> a8a59477268d 2 weeks ago 445MB
mysql 8.0 c01d431b7858 10 months ago 266MB
phpmyadmin/phpmyadmin <none> 7af57eae1e90 3 weeks ago 163MB
phpmyadmin/phpmyadmin latest 3405a88394e3 9 months ago 111MB

带标签的都是官方仓库的基础镜像，而的是Swarm部署时生成的临时镜像，多出来的大小就是刚才说的那些额外处理层占用的空间。比如mysql的临时镜像比基础镜像大了近200MB，大概率是包含了数据库初始化的临时数据、环境变量注入层，或者Swarm为了服务高可用添加的一些内部适配逻辑。

这些镜像需要处理吗？ #

完全不用慌，这是Swarm部署的正常现象。当你更新服务或者删除服务后，这些临时镜像会变成无引用的虚悬镜像，你可以用docker image prune命令安全清理它们，不会影响正在运行的服务。

题外话：你的Stack配置小提示 #

看到你说当前配置还没法运行，刚好提个小细节：在Swarm的deploy配置块里，restart: always是无效的，Swarm用的是restart_policy字段来配置重启策略，比如：

deploy:
  restart_policy:
    condition: on-failure
    delay: 5s
    max_attempts: 3
    window: 120s

不过这都是后话，你现在专注学习Swarm部署流程就好~

内容的提问来源于stack exchange，提问作者hwkd