Docker镜像层的物理不可变性由存储驱动底层机制保障，非权限控制；每层按内容生成唯一SHA256哈希，作为目录名直接映射磁盘路径，只读层通过联合挂载锁定，所有运行时修改均隔离至可写层，重启即还原确定状态。
只读镜像层的物理不可变性，不是靠权限控制“不让改”，而是由存储驱动底层机制保障的“根本改不了”——它让生产环境每次启动都回到一个被验证过的确定状态。
镜像层按内容寻址，哈希即身份
每个镜像层在构建完成后生成唯一 SHA256 哈希值，该值由层内全部文件内容精确计算得出。只要内容有一字节差异，哈希就完全不同。Docker 存储驱动（如 overlay2）将该哈希作为目录名和索引键，直接映射到磁盘上的 /var/lib/docker/overlay2/abc123/diff 目录。这个路径一旦创建，其内容就被锁定：系统不提供任何接口修改该目录下的原始文件；即使 root 用户也无法覆写或删掉它——因为 overlay2 的只读层是通过联合挂载（union mount）以只读方式叠加进容器视图的，写操作天然被重定向至上层。
运行时所有变更都隔离在可写层
容器启动时，Docker 会在镜像最上层动态添加一个空的可写层（upperdir），所有运行时产生的文件、日志、临时缓存、甚至 pip install 或 echo 写入，都只会落在这一层。原始镜像层中的 Python 解释器、requirements.txt 指定的 torch==2.4.0、Nginx 配置、模型权重文件等，物理上保持字节级一致：
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 你在容器里执行 rm -f /usr/bin/python3，实际只是在可写层标记该路径为“已删除”，镜像层里的 python3 文件依然完整存在
- 误升级 pip 或覆盖 config.json，重启容器后自动消失，因为可写层随容器生命周期销毁
- 多个容器共享同一镜像层，彼此写操作互不影响，基础依赖零干扰
稳定性来自“启动即还原”的确定性
生产环境中，服务可能因异常中断、滚动更新、节点迁移而频繁重建容器。只读层机制确保每次 docker run 启动的都不是“上次留下的那个状态”，而是干净、一致、与构建时完全相同的初始环境：
- 不会出现“测试环境能跑，生产报 ImportError”——因为 import 路径、so 库版本、文件权限全固化在镜像层中
- 无需人工清理残留配置或缓存，也无需担心日志填满根分区——这些都被限制在临时可写层或显式挂载的 volume 中
- 故障回滚只需拉取旧版镜像哈希重新部署，无需校验每台机器的 Python 包列表或系统库版本
防篡改不是附加功能，而是分层架构的自然结果
启用 --read-only 参数只是进一步关闭可写层的写入口，但即便不加，镜像层本身也无法被覆盖。真正的稳定性保障在于：攻击者即使获得容器内 root 权限，也无法持久化修改核心二进制或配置——他只能污染当前运行实例的顶层，而该污染在容器终止后即刻清零。这种“物理不可变 + 启动即还原”的组合，把环境一致性从运维习惯升格为系统级保障。
