docker commit只保存容器可写层变更，不保存挂载卷内容，这是为保障镜像可移植性与无状态性的设计特性；它捕获文件修改、软件安装等容器层变化，但绕过-v或--mount挂载的宿主机路径。
掌握 docker commit 的原理，关键在于理解它只保存容器的“可写层变更”，而完全不捕获挂载卷（Volume/Bind Mount）中的内容。这不是 bug，而是设计使然——镜像必须可移植、无状态，而挂载数据属于运行时环境，理应与镜像解耦。很多持久化失败，恰恰是因为误以为 commit 能把 -v 挂载的数据一起打包进去。
一、commit 只拍“容器层快照”，不碰挂载点
Docker 容器文件系统由三部分组成：
- 只读镜像层：来自基础镜像，不可修改
- 可写容器层：运行时所有新增、修改、删除的文件都发生在这里（如 apt install、echo 写配置、替换 conf 文件）
-
挂载点（-v / --mount）：独立于联合文件系统的外部路径，比如
-v mysql-data:/var/lib/mysql或-v ./data:/app/data
执行 docker commit my_container new_image 时，Docker 仅将第二项（可写层）的差异打包成新镜像层。第三项的内容——无论你往 /var/lib/mysql 里写了多少数据——都不会出现在新镜像中。你可以用 docker inspect my_container | jq '.[0].Mounts' 查看挂载详情，确认它们被明确标记为外部来源。
二、常见持久化误区及对应正解
误区往往出现在混淆“保存容器状态”和“保存业务数据”：
-
错误做法：在容器内手动向
/var/www/html放网页文件，再commit，以为下次run就能直接访问 —— 实际上这些文件进了镜像，但若同时挂载了-v ./html:/var/www/html，挂载会覆盖镜像里的内容，导致“看不见” -
正确分工：
- 用
commit固化软件安装、配置模板、启动脚本等环境层变更（例如：装好 nginx + 配置好 default.conf） - 用 命名卷（named volume）或绑定挂载 管理动态生成的业务数据（例如：用户上传的图片、数据库文件、日志）
- 用
-
典型反例：运行
docker run -v /data mysql（匿名卷），调试完数据库后commit，再run新容器却找不到原数据 —— 因为匿名卷每次启动都新建，且commit也没把它存进去
三、安全高效的 commit 实践组合
真正发挥 commit 价值，需配合明确目的与规范流程：
-
调试定版：容器内完成复杂配置后，立即
docker commit -m "JVM tuned + GC log enabled" app_container app:debug-v2，避免重复操作 -
依赖预装镜像：对慢速构建的基础镜像（如 python + 大量 pip 包），先
run -it手动安装，再commit成新基础镜像，后续 DockerfileFROM它，跳过耗时步骤 -
规避风险操作：
- 不提交含敏感信息的容器（如硬编码密码的配置文件），可用
--change动态覆盖 CMD/ENTRYPOINT，避免把密钥写进镜像层 - 提交前用
docker diff my_container检查实际变更，确认没误改系统文件（如 /etc/hosts） - 生产环境禁用
commit直接上线，它适合开发/测试快照，正式交付仍应通过 Dockerfile 构建+CI 验证
- 不提交含敏感信息的容器（如硬编码密码的配置文件），可用
四、替代方案对比：什么情况该换思路？
当需求超出 commit 能力边界时，应主动切换方法：
-
需要版本可控、可审计的配置变更 → 改用 Dockerfile + 构建参数（
--build-arg）或配置中心 -
多环境差异化部署（dev/staging/prod） → 用
docker compose的env_file或 profiles，而非靠多个 commit 标签管理 -
挂载数据也要“备份/迁移” → 不靠 commit，而用
docker run --rm -v mysql-data:/volume -v $(pwd):/backup alpine tar czf /backup/mysql-backup.tar.gz -C /volume .
