升级 Docker 大版本时，部分 CLI 命令、参数或子命令会被正式废弃或移除，需查阅官方变更日志、运行 help 对比标记为 [DEPRECATED] 的选项，并用 grep 扫描脚本中的风险调用，再通过兼容写法、版本判断和执行验证完成适配。
升级 Docker 大版本（如从 1.x → 20.x，或 23.x → 24.x）时，部分 CLI 命令、参数甚至子命令会被正式废弃或移除，导致原有自动化脚本执行失败。这不是偶然报错，而是设计上的行为变更，必须主动识别和适配。
确认哪些命令已被废弃
新版 Docker 会明确标记弃用项，并在运行时输出 DEPRECATED 警告；升级后首次执行旧命令可能直接报错（如 docker login -e 已被移除）。关键动作：
- 查阅对应版本的官方变更日志（如 Docker Engine Release Notes），重点关注 “Deprecated” 和 “Removed” 板块
- 运行
docker --help或docker <subcommand> --help，对比新旧输出，留意带 [DEPRECATED] 标记的选项 - 常见已废弃项示例：
•docker login -e（邮箱参数自 17.06 起无作用，24.x 直接报错）
•docker run --storage-opt（交由 containerd 统一管理，Docker CLI 不再透传）
•docker info -f '{{.Driver}}'（Go 模板字段名变更，如 24.x 中部分字段移入.ServerErrors或结构重组）
批量扫描脚本中的风险调用
不要靠人工逐行翻查。用简单命令快速定位：
- 搜索所有 shell 脚本中含
docker的行并过滤典型弃用模式：grep -r "docker.*login.*-e\|docker.*run.*--storage-opt\|docker.*info.*-f" /path/to/scripts/ - 检查是否使用了已删除的子命令，如：
docker events --since（旧版支持字符串，新版要求 RFC3339 时间格式）docker system df -v（-v在 24.x 中已移除，改用--verbose） - 若脚本含 Go 模板（
-f参数），需验证字段是否存在——可临时加--debug运行，观察实际返回 JSON 结构
安全替换策略：兼容写法 + 版本判断
避免“一刀切”重写全部脚本。推荐渐进式处理：
- 对已移除的参数，优先用等效新方式替代：
•docker login -u user -p pass registry.example.com（去掉-e）
•docker system prune -f --filter "until=24h"替代过时的--before用法 - 对跨版本行为不一致的命令（如
docker ps输出字段顺序、空值表示），改用--format显式指定，而非依赖默认列宽或空格分隔 - 必要时做版本分支判断（适用于长期维护的通用脚本）：
if [ "$(docker version --format '{{.Server.Version}}' | cut -d. -f1)" -ge 24 ]; then ... fi
升级后必做验证项
仅改代码不够，要验证执行结果语义是否一致：
- 运行修改后的脚本，检查退出码是否为 0，且关键输出（如容器 ID、镜像 digest、状态字段）符合预期
- 特别注意涉及权限、认证、过滤逻辑的命令——例如
docker images --filter "dangling=true"在新版中含义未变，但--filter "label=xxx"若 label 值含特殊字符，需确认是否需额外转义 - 若有 CI/CD 流水线调用 Docker 命令，务必在升级后触发一次全链路回归，而非只测单步命令
