windows上powershell中docker run -v挂载路径必须写成c:/path格式，即带驱动器前缀、正斜杠、不加引号、不省略盘符，否则报“no such file or directory”。
Windows 上用 PowerShell 跑 docker run -v，路径必须写成 C:/path 格式，不能用反斜杠、不能省驱动器、不能用 //wsl$/ 或 /host_mnt/ —— 写错就报 “no such file or directory”。
PowerShell 里 -v 参数的路径怎么写才对
PowerShell 本身支持正斜杠和反斜杠混用，但 Docker Desktop 的绑定挂载机制只认一种格式：带驱动器前缀 + 正斜杠。这不是 PowerShell 的限制，而是 Docker 在 Windows 上解析宿主机路径的硬性规则。
-
C:\data❌（反斜杠，CMD 下可能侥幸成功，PowerShell 里常被当作转义序列处理） -
C:/data✅（唯一稳定写法，PowerShell 和 CMD 都兼容） -
//wsl$/ubuntu-22.04/home/user/project❌（这是容器内看到的 WSL 路径，不是宿主机路径） -
/host_mnt/c/data❌（这是旧版 Hyper-V 后端遗留路径，WSL2 后端已弃用） -
"C:\my project"❌（加引号没用，Docker 不会解析引号里的空格） -
C:/my project✅（含空格或中文的路径，直接写，无需引号）
为什么 C:/path 能行，而 C:\path 经常失败
根本原因是 Docker Desktop 在 Windows 上通过 WSL2 后端运行时，会把 -v 参数中的宿主机路径交给 WSL2 的文件系统桥接层处理。该桥接层只识别 POSIX 风格路径（即正斜杠），且要求驱动器必须显式写出。反斜杠在 PowerShell 中会被部分解析为转义字符（比如 \n、\t），导致路径截断或语义错误。
- 执行
docker run -v C:\data:/app ubuntu:22.04时，PowerShell 可能先将\d解释为退格符，最终传给 Docker 的是损坏路径 - 即使没触发转义，Docker 内部路径解析器仍会拒绝
C:\data，返回invalid argument或静默挂载为空目录 -
C:/data完全绕过 PowerShell 转义，且符合 WSL2 桥接协议预期，所以最可靠
挂载前必须检查的三个状态
路径写对只是第一步；如果 Docker Desktop 还没被授权访问对应磁盘，或者 WSL2 实例卡住，照样挂载失败——而且错误信息往往误导人，看起来像路径问题。
- 右键任务栏 Docker 图标 → Settings → Resources → File Sharing，确认目标盘符（如
C:）已勾选，右侧无红色警告图标 - 执行
wsl --list -v，确保docker-desktop和docker-desktop-data状态都是Stopped或Running，不是Stopping或空白 - 若刚改过共享设置，必须点 Apply & Restart，等状态栏显示 “Docker Desktop running” 才算生效；只重启 PowerShell 没用
验证挂载是否真正双向同步
别只进容器 ls /mnt 就以为成了。Windows 和容器间的文件同步有延迟窗口，且权限模型不一致，容易误判。
- 在宿主机创建测试文件：
echo "host" > C:/test/hello.txt - 启动容器：
docker run -it -v C:/test:/mnt alpine:latest - 在容器内执行：
echo "container" >> /mnt/world.txt && ls -l /mnt（应看到两个文件） - 退出后，立即在 Windows 资源管理器打开
C:\test，确认world.txt已存在且内容正确 - 如果文件没出现，优先检查 File Sharing 授权和 WSL2 状态，而不是怀疑路径写法
最常被忽略的是：挂载成功 ≠ 实时可写。WSL2 文件桥接在大量小文件场景下会有明显延迟，且 Windows 创建的文件默认没有 Linux 的执行位。开发中若依赖 chmod 或频繁 stat，得接受这个现实，或者换用命名卷 docker volume 做中间层。
