Bind Mount核心是路径可控、权限明确、环境匹配，专用于开发调试、配置共享、日志采集等场景，禁用于生产数据库；需提前创建宿主机路径并设权，用绝对路径和精准选项（如:ro），挂载后必须验证双向同步与权限行为。
Bind Mount 方案设计核心是“路径可控、权限明确、环境匹配”。它不是通用数据存储方案，而是为特定协作场景服务的——比如开发时代码热更新、配置文件共享、日志临时采集等。设计时重点不在“能不能挂”，而在“挂得是否安全、稳定、可维护”。
明确挂载目的与生命周期
先问清楚：这个挂载是为了让谁读写？数据要不要跨容器共享？容器删了，宿主机上的文件还留不留？
- 开发调试：挂源码目录，用
$(pwd):/app，要求实时双向同步，容器内进程需有写权限 - 只读配置分发：挂
/etc/config，加:ro，避免容器误改配置引发故障 - 日志收集过渡：挂
/var/log/myapp到宿主机临时目录，方便脚本定时归档，不长期留存 - 避免用于数据库数据：Bind Mount 不提供快照、备份、迁移能力，生产数据库必须用 Volume
宿主机路径必须提前创建并设权
Docker 不再自动创建缺失的宿主机路径（23.0+ 版本默认报错），且挂载后权限继承自宿主机目录，而非容器用户。
- 手动执行
mkdir -p /host/data && chown 1001:1001 /host/data（1001 是容器内应用用户的 UID/GID） - 避免用 root 用户挂载再让非 root 容器进程写入，容易因权限拒绝失败
- 路径尽量用绝对路径，不用相对路径或符号链接（Docker 解析不稳定）
挂载选项要精简、精准
-v 后面的冒号三段式写法：宿主机路径:容器路径[:选项]，选项只写真正需要的。
- 读写默认开启，无需显写
:rw；只读必加:ro - 避免滥用
:z或:Z（SELinux 标签），除非真在启用 SELinux 的系统上运行 - 不加
consistency:cached等 macOS 特有选项，否则 Linux 主机运行会报错 - 多个挂载用多个
-v，别堆在一个参数里
验证挂载行为是否符合预期
启动后立刻检查，不能靠“应该没问题”跳过验证。
- 进容器
docker exec -it 容器名 sh，确认ls -l /挂载路径显示内容与宿主机一致 - 在容器内
touch /挂载路径/test，回宿主机看是否生成；若挂:ro，该命令应报Read-only file system - 删容器再重跑，检查宿主机文件是否保留（Bind Mount 天然保留）、内容是否未被覆盖
- 两个容器挂同一宿主机目录时，确认它们看到的是同一份文件（注意并发写风险）
