Windows Docker Desktop 多目录映射必须在启动容器时用多个 -v 参数（如 -v D:/project:/app -v D:/logs:/app/logs），不可追加到已运行容器；需提前在 File Sharing 中勾选对应盘符，路径用正斜杠，含空格需加双引号，且宿主机目录须手动创建并设完全控制权限。
不能直接给已运行的容器“追加”多个挂载点，必须重建容器或改用 docker-compose 管理——这是 Windows Docker Desktop 下多目录映射最常被误踩的起点。
docker run 里用多个 -v 参数一次挂载
最直接的方式是在启动容器时用多个 -v 或 --volume 参数。Windows 路径需用正斜杠或双反斜杠，且必须提前在 Docker Desktop 的 File Sharing 设置中勾选对应盘符（比如 D: 或 C:\Users）。
- 错误示例：
docker run -v C:\data:/app/data -v C:\conf:/app/conf nginx→ 报错invalid mount config，因路径未共享或含空格/中文 - 正确写法（推荐正斜杠）：
docker run -d --name myapp -v D:/project:/app -v D:/logs:/app/logs -v D:/config:/etc/myapp nginx - 若路径含空格，必须用双引号包裹宿主机部分：
-v "D:/my project":/app - 每个
-v是独立挂载，权限、只读控制可分别指定，例如：-v D:/data:/data:ro -v D:/cache:/cache:rw
docker-compose.yml 中声明多个 volumes
适合长期维护或涉及多个容器的场景。Docker Desktop 会自动识别 volumes 块里的所有条目，无需额外操作。
- 注意路径分隔符：YAML 中仍用正斜杠，
./src表示相对于docker-compose.yml所在目录的路径 - 示例片段：
services:
web:
image: nginx
volumes:
- D:/www:/usr/share/nginx/html:ro
- D:/nginx/conf.d:/etc/nginx/conf.d:ro
- D:/logs:/var/log/nginx- 如果某容器（如 PHP）和 Web 容器需共用代码目录，两个 service 都要声明相同路径，否则 PHP 容器内看不到 Nginx 挂载的文件（见 Devilbox 实践）
- 避免使用
./开头的相对路径映射到根目录级位置（如./:/hostroot），Windows 文件权限可能引发Permission denied
挂载后容器内目录被清空或不可写？检查三件事
这不是挂载失败，而是 Windows 与 Linux 用户权限、路径存在性、挂载时机共同作用的结果。
- 宿主机路径不存在时，Docker Desktop 会自动创建空目录，但该目录属 NTFS 默认用户，容器内 UID=0（root）可能无权写入 —— 解决办法：提前手动创建目录，并右键属性 → 安全 → 编辑 → 添加
Everyone或具体用户并赋予“完全控制” - 容器启动早于宿主机目录就绪（尤其 WSL2 启动慢），导致挂载点为空 → 改用
docker-compose up --force-recreate或确保目录先存在再up - 映射路径末尾带斜杠（
D:/data/）和不带（D:/data）在某些镜像行为不同，建议统一不带尾部斜杠，避免意外覆盖
为什么不用 bind mount + mount --bind 在容器里二次挂载？
有人想绕过重建容器，在运行中用 docker exec -it container_name mount --bind 加新目录。这在 Docker Desktop（WSL2 后端）下基本无效。
- WSL2 内核默认禁用
mount命令，即使容器是特权模式，也会报operation not permitted - 即便临时启用，该挂载仅存在于当前容器生命周期，重启即失效，且无法被其他容器感知
- 更关键的是：Docker Desktop 的文件共享机制（9P/virtio-fs）不支持运行时动态注入新共享路径，必须通过
File Sharing设置预注册
真正麻烦的不是“怎么写多个 -v”，而是 Windows 权限模型和 WSL2 文件系统桥接带来的隐性约束——每次新加一个映射，都要确认它是否已在 Docker Desktop 的共享列表里、宿主机目录是否存在且可访问、以及有没有被另一个容器抢先创建了同名空目录。这些细节不显眼，却决定挂载到底“通不通”。
