容器修改不影响镜像，靠的是 docker 的分层文件系统 + 可写层隔离机制；镜像由只读层叠加构成，运行时所有写操作仅发生在独立可写层，删除容器即销毁该层，镜像保持不变。
容器修改不影响镜像，靠的是 docker 的分层文件系统 + 可写层隔离机制，不是靠人工“避免修改”，而是底层设计就天然隔开。
镜像的只读分层结构
镜像由多个只读层（Layer）叠加组成，比如基础系统层、运行时层、应用代码层。每一层都是静态的、不可变更的。你执行 docker images 看到的镜像 ID，实际指向的是这一整套只读层的组合快照。
- 所有层都用内容寻址（如 SHA256 哈希）标识，相同内容层可被多个镜像共享
- 构建时每条
RUN、COPY指令生成一个新层，但不会改动已有层 - 镜像本身没有“运行态”，它不占用内存或 CPU，只是一个磁盘上的模板文件集合
容器启动时自动挂载可写层
当你运行 docker run nginx:alpine，Docker 守护进程会在镜像最顶层动态添加一个全新的、空的可写层（也叫“容器层”或“top layer”）。所有运行时操作——写日志、创建临时文件、改配置、安装包——都只发生在这个层里。
- 这个可写层与镜像层完全分离，删除容器时该层自动销毁，镜像毫发无损
- 同一镜像启动 10 个容器，就产生 10 个独立可写层，彼此互不干扰
- 即使你在容器里执行
rm -rf /usr/bin，也只是删了自己那层的符号链接，底层镜像的二进制文件依然完好
需要持久化修改？走正规路径
如果确实想保留某次运行中的改动（比如调试后修好的配置），不能靠“别删容器”，而应主动固化：
-
推荐方式：用
docker commit <container-id> new-image-name</container-id>把当前可写层打包成新镜像（含原镜像所有只读层 + 新增的修改层） -
生产推荐：把修改逻辑写回
Dockerfile，用docker build重建镜像——这样可复现、可版本控制、符合不可变基础设施原则 -
运行时数据：敏感或频繁变动的数据（如数据库文件、上传目录）应通过
-v挂载宿主机目录或命名卷（volume），完全绕过容器层
这套机制不是约束，而是保障：你随便折腾容器，镜像永远稳如磐石；想升级模板，就重新构建镜像，而不是在运行实例上打补丁。
