这类问题我又碰上了一次。Ubuntu 22.04 上 Docker Compose v2.20，改完 docker-compose.yml 里的 image 从 1.3 到 1.4，执行 docker compose up -d 之后页面功能没变，容器里的版本号还是 1.3。
第一反应是「改了 image 却漏了 build 段，服务其实一直在用本地构建的旧镜像」，验证下来不成立。
排查方向其实有限，先把可能性排一排。compose 只在配置变化时重建容器，镜像 tag 变了但容器已经存在，默认不会拉新镜像；本地早就有同名 latest 镜像，pull 策略走的是本地缓存；多副本部署时只重建了一个服务，另一个还在跑旧容器。
上来先看容器实际用的镜像 ID 和创建时间
docker inspect web -f '{{.Config.Image}} {{.Image}} {{.Created}}'强制拉取新镜像再重建
docker compose pull web && docker compose up -d --force-recreate web再往下对比本地镜像的摘要是否一致
docker images --digests | grep web等前面都确认过，再确认新容器里的版本号
docker compose exec web ./app --version怎么算真的好了，看的是同一批现象。容器内版本号显示 1.4，docker inspect 的 Image 摘要与仓库里 1.4 的 digest 一致，页面功能与发布说明对得上。
用固定版本号不要用 latest，latest 每次都靠人猜；重建前先 pull，否则 compose 只会拿本地那份镜像重开容器。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。