Bind Mount 在研发环境应仅用于代码热更新和本地配置共享，禁止挂载日志、数据库等需持久化的数据；路径须为绝对路径且预创建，权限需匹配容器用户；挂载选项应显式声明 rw/ro；开发与生产挂载逻辑须分离，通过独立 compose 文件管理。
Bind Mount 在研发环境里用得对，能极大提升开发效率；用得不对，反而埋下隐患。核心不是“能不能用”，而是“怎么用才安全、可控、可复现”。
明确用途：只用于代码热更新和本地配置共享
Bind Mount 的本质是把宿主机目录实时映射进容器，所以它天然适合两类场景：
- 源码开发调试：比如
docker run -v $(pwd):/app node:18-alpine，改代码后应用（配合 nodemon 或 ts-node watch）自动重启 - 本地配置注入：如把
./config/local.yaml挂到容器内/app/config.yaml，避免每次构建镜像都打包配置
不建议用它挂日志目录、数据库文件或任何可能被容器写入且需长期保留的数据——这类数据该交给 Volume 管理。
路径必须绝对、存在且权限合理
Bind Mount 要求宿主机路径是绝对路径，且最好在运行前手动创建好：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 别依赖 Docker 自动创建目录（新版本会报错），先执行
mkdir -p /home/user/myapp/src - 检查宿主机目录权限：如果容器以非 root 用户（如
USER node）运行，宿主机对应目录需对该用户可读写，否则启动失败或静默失败 - 避免挂载整个家目录或根目录——最小化暴露范围，防止误删或越权访问
挂载选项要显式声明读写行为
默认是读写，但显式标注更清晰、更安全：
- 开发时常用：
-v $(pwd):/app:rw—— 明确允许容器修改宿主机代码 - 挂配置文件时用：
-v ./config/dev.env:/app/.env:ro—— 防止容器意外覆盖配置 - 禁止写入敏感路径，比如不要把
/etc或/var/log直接挂进去
不混用生产与开发挂载逻辑
同一份 docker-compose.yml 不该同时适配开发和生产。推荐分拆：
-
docker-compose.dev.yml：含 Bind Mount、热重载工具、dev-only 服务（如 mock server） -
docker-compose.prod.yml：用 Volume、关闭挂载源码、启用健康检查和资源限制 - 通过
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up组合使用
这样既保证开发便捷性，又杜绝了 .gitignore 漏掉敏感挂载路径、或误将 dev 配置推到生产环境的风险。
