命名卷（Named Volume）可确保镜像升级后自动复用数据，因其生命周期独立于容器，只要卷名和挂载路径不变，数据即自然延续；需显式使用-v myapp_data:/app/data挂载，避免误建匿名卷。
升级应用镜像后，旧数据能直接复用——前提是容器启动时正确挂载了命名卷或绑定挂载，且没误删卷。否则数据就丢了，不是镜像升级的问题，而是持久化没做对。
命名卷（named volume）如何确保升级后自动复用
命名卷是 Docker 推荐的数据持久化方式，它独立于容器生命周期，升级镜像时只要卷名不变、挂载路径一致，数据就自然延续。
-
docker run启动新容器时必须显式使用-v myapp_data:/app/data（不能只写/app/data，那会创建匿名卷） - 检查卷是否存在：
docker volume inspect myapp_data；若报错说明卷不存在，得从备份恢复 - 升级时别用
docker rm -f然后手动docker run，推荐用docker-compose up -d --force-recreate --no-deps，它会保留原有卷绑定 - 注意权限：新镜像的
USER指令可能改了运行用户，导致旧卷内文件不可读，可在启动时加--user root临时调试，再修复属主
绑定挂载（bind mount）路径变更导致数据“消失”的典型场景
绑定挂载依赖宿主机绝对路径，升级镜像时如果 docker run 命令里写的挂载路径变了（比如从 ./data 改成 ./v2/data），容器就看不到旧数据了——其实文件还在原处，只是没挂进去。
- 确认路径是否真实存在：
ls -l ./data（Linux/macOS）或dir .\data（Windows CMD） - Windows 用户特别注意路径格式：WSL2 下用
/mnt/c/Users/xxx/project/data，不要用C:\xxx\project\data，后者在容器内不可见 - Docker Desktop for Windows 默认启用「Use the WSL2 based engine」，绑定挂载性能比 Hyper-V 好，但路径映射规则更严格
- 若路径没错却读不到数据，检查容器内挂载点是否被镜像里的初始化脚本清空过（比如某些 Node.js 镜像会在
ENTRYPOINT里执行rm -rf /app/data/*）
升级后容器启动失败，查数据卷相关错误的三步定位法
常见报错如 permission denied、cannot create directory、database is locked，多数和卷复用有关，而非镜像本身问题。
- 先看容器日志：
docker logs <container_name></container_name>，重点找路径 open/read/write 失败的行 - 进容器验证挂载状态：
docker exec -it <container_name> sh -c "ls -ld /app/data && mount | grep data"</container_name> - 对比新旧镜像的 UID/GID：运行
docker run --rm <old_image> id -u</old_image>和docker run --rm <new_image> id -u</new_image>，若不一致，旧卷文件属主可能不匹配
最常被忽略的一点：Docker Desktop 升级后，docker-desktop-data 这个 WSL2 发行版有时会重置，导致所有命名卷“凭空消失”——这不是你操作错了，而是 Desktop 的 WSL2 数据迁移逻辑出问题。遇到这种情况，别急着重装，先运行 wsl -l -v 确认 docker-desktop-data 是否还在，再查 %LOCALAPPDATA%\Docker\wsl\data\ 下的 ext4.vhdx 文件大小是否归零。
