必须配合tmpfs挂载才能启用read_only:true，否则因/run等路径不可写导致启动失败；:ro仅限制单个卷，不等于容器根文件系统只读；Windows下需确认使用WSL2后端以保障tmpfs正常工作。
在 Docker Desktop 中无法直接“创建只读文件系统容器”——必须通过 read_only: true + tmpfs 显式组合才能生效，否则容器根本起不来。
docker-compose.yml 里用 read_only: true 启动就报错？
这是最常见现象：容器日志里卡在 mkdir: can't create directory '/run': Read-only file system 或类似错误。根本原因是 read_only: true 会让整个 rootfs（包括 /tmp、/run、/var/run）变只读，但几乎所有 Linux 服务（nginx、redis、supervisord 等）启动时都要往这些路径写 pid 文件、socket、锁或临时缓存。
- 必须显式挂载
tmpfs覆盖这些路径，不能依赖默认行为 -
tmpfs挂载点必须写全路径，比如/run和/var/run不能只写一个——很多镜像会 symlink 其中之一，但挂载点不匹配照样失败 - Alpine 镜像尤其敏感，
/var/run和/run常同时被使用，两个都得挂
volumes 里用 :ro 不等于容器根文件系统只读
很多人误以为给某个 volume 加 :ro 就实现了“只读容器”，其实这只是限制了那个挂载点（如 /etc/nginx/conf.d），容器内其他路径（/app、/usr/local/bin）依然可写，镜像层里的文件也能被覆盖（copy-on-write）。
-
./config:/etc/nginx/nginx.conf:ro→ 只保护这个配置文件不被改 -
./html:/usr/share/nginx/html:ro→ 只保护静态资源目录 - 但
/var/cache/nginx、/tmp这些路径仍可写，除非你额外加read_only: true服务级配置 - 混合使用时注意优先级：
read_only: true是全局开关，:ro是局部约束，两者不冲突，但目标不同
Windows Docker Desktop 下 tmpfs 有兼容性限制
WSL2 后端对 tmpfs 的支持基本完整，但如果你在 Windows 上用的是 Hyper-V 后端（极少见，已基本弃用），tmpfs 可能不生效或行为异常。Docker Desktop 默认启用 WSL2，但需确认：
- 打开 Docker Desktop → Settings → General → ✔️ “Use the WSL 2 based engine”
- 命令行执行
docker info | grep "Default Runtime"，输出应含runc（不是vmware或hyperv） -
tmpfs在 WSL2 下无需额外配置，但挂载大小不能设为size=0（会触发内核 panic），建议留空或设明确值如size=64m
真正容易被忽略的点是：即使加了 read_only: true 和全套 tmpfs，如果应用代码里硬编码了往 /app/config.yaml 这类镜像层路径写配置，容器照样会崩——只读保护拦不住运行时的写操作，只能靠代码自己守规矩或用 init 容器预生成。
