docker镜像必须只读，因其本质是按序叠加的只读层，通过联合文件系统合并为统一视图；只读性保障一致性、支持分层复用、防止环境漂移，并依托内容哈希实现缓存与安全分发。
docker 的只读文件系统不是限制，而是设计哲学的核心体现。它保障镜像一致性、支撑分层复用、避免运行时污染，是容器可重现、可分发、可信任的底层基础。
镜像为什么必须只读？
镜像本质是一组按顺序叠加的只读层（Layer），每一层对应一个构建指令（如 RUN apt install 或 COPY app.py）。这些层通过联合文件系统（如 Overlay2）合并成一个逻辑视图。只读性确保：
- 同一镜像启动的多个容器，共享底层所有只读层，极大节省磁盘与内存
- 镜像内容不可被运行中的容器意外修改，杜绝“环境漂移”
- 层通过内容哈希（Content Hash）唯一标识，相同操作生成相同层，天然支持缓存与复用
- 镜像可安全推送到仓库、跨主机拉取，行为完全确定
容器运行时的读写层怎么工作？
当你执行 docker run 启动容器，Docker 引擎会在镜像最顶层自动附加一个**可读写层（Read-Write Layer）**。所有运行时变更——比如创建日志、写入临时文件、修改配置——都发生在此层，不触碰任何底层只读镜像层。
关键机制是写时复制（Copy-on-Write, CoW）：当容器首次修改一个存在于只读层的文件（如 /etc/hosts），Docker 会先将该文件从底层完整复制到读写层，再进行编辑。原只读层文件保持不变，仅被新版本“遮蔽”。
这意味着：
- 容器停止或删除后，读写层随之销毁，所有运行时改动消失
- 重启同一镜像产生的新容器，起始状态与原始镜像完全一致
- 若需持久化数据，必须显式使用 Volume 或 Bind Mount
如何真正控制只读行为？三种典型场景
1. 挂载 Volume 为只读
适用于共享配置、静态资源等不希望被容器篡改的场景：
docker run -v my-config:/etc/app:ro nginx
:ro 标志强制挂载点只读，任何写入操作（如 echo "x" > /etc/app/config.yaml）将报错 Read-only file system。
2. 整个容器根文件系统设为只读
提升安全性，防止恶意或缺陷程序破坏系统路径：
docker run --read-only -tmpfs /tmp -tmpfs /run nginx
--read-only 禁止对 / 下所有路径写入；但需配合 tmpfs 挂载必要临时目录（如 /tmp），否则进程可能因无法写 pid 或 socket 而失败。
3. Docker Compose 中声明只读策略
在 docker-compose.yml 中统一管控：
services:
api:
image: my-api:latest
read_only: true
tmpfs:
- /tmp
- /var/run
volumes:
- logs:/var/log/myapp:rw
其中 logs 卷仍可读写，而整个容器根目录和其他挂载默认只读，策略清晰、易于审计。
常见误区与避坑提醒
❌ 认为 docker commit 保存的是“完整容器快照”
→ 实际只打包读写层中被修改或新增的文件，未变动的只读层仍引用原始镜像层。生成的新镜像依然由只读层构成。
❌ 把容器内 /proc、/sys 或 /dev 当作普通目录挂载并设为只读
→ 这些是内核虚拟文件系统，挂载方式特殊，强行只读可能导致容器无法启动或功能异常。应交由 Docker 自动管理。
❌ 在 Dockerfile 中用 RUN chmod -R 777 /app 试图“绕过只读”
→ 构建阶段的修改会固化为新只读层，不影响运行时行为；且开放权限反而降低安全性，违背最小权限原则。
✅ 正确思路是：构建时精简只读层（多阶段构建、删除缓存）、运行时用只读约束+必要 tmpfs/Volumes 补充写能力。
