必须将项目放在 Windows 原生路径（如 D:projectsmyapp），而非 wsl$ 路径，因后者通过 9P 协议桥接，I/O 延迟高、不支持 inotify，导致 npm install 卡死、热重载延迟严重。
项目代码不要放在 \wsl$ 路径下（比如 \wsl$docker-desktop-data），而应放在 Windows 原生文件系统中，例如 D:projectsmyapp。WSL2 的跨文件系统访问性能极差，尤其在 Node.js、Python 等需要频繁读写 node_modules 或 .pyc 的场景下，会导致 npm install 卡死、docker build 极慢、热重载延迟严重。
为什么不能把项目放 \wsl$ 下
WSL2 本质是轻量虚拟机，\wsl$ 是 Windows 主机通过 9P 协议挂载进 WSL 的“桥接路径”，不是本地磁盘。所有 I/O 都要经由主机内核转发，没有缓存、不支持 inotify、stat 调用延迟高（常达 10–50ms）。实测对比：
- 在
D:projects下执行npm run dev：启动 2.3 秒，文件变更响应 - 在
\wsl$docker-desktop-datahomeuserproject下同样操作：启动 18 秒，变更响应 2–5 秒，且经常触发重复编译
这不是配置问题，是架构限制——微软官方文档明确标注 “\wsl$ is not intended for development”。
docker build 时 -f 和 . 路径必须一致
构建上下文（build context）和 Dockerfile 路径都得基于 Windows 原生路径，否则会报错或静默失败。常见错误包括：
-
docker build -f \wsl$docker-desktop-data...Dockerfile .→ 报错Cannot locate specified Dockerfile -
docker build -f D:Dockerfile D:projectsmyapp→ 正确，但要求D:projectsmyapp中不含中文、空格、特殊符号 - 若 Dockerfile 在子目录（如
D:projectsmyappdockerDockerfile），则必须用-f D:projectsmyappdockerDockerfile -t myapp .，且最后的.指向的是D:projectsmyapp（即上下文根），不是 Dockerfile 所在目录
Windows 路径中的反斜杠 在 PowerShell 中需转义或改用正斜杠；CMD 下直接用 即可，但建议统一用 / 避免歧义。
挂载卷（-v）必须用 Windows 路径格式
从 Windows 启动容器时，宿主机路径必须写成 D:/projects/myapp 或 D:\projects\myapp，不能写成 /d/projects/myapp（那是 WSL 的路径映射，Docker Desktop 不识别）。
- 正确：
docker run -v D:/projects/myapp:/app -w /app python:3.11 pip list - 错误：
docker run -v /d/projects/myapp:/app ...→ 容器内/app为空，因为 Docker Desktop 根本没找到宿主机路径 - 若路径含空格（如
D:My Project），必须加双引号："D:My Project"，否则 CMD/Powershell 会截断
注意：WSL2 内部的 /mnt/d/ 是只读映射，不可用于 -v 挂载；只有 Windows 原生路径才能被 Docker Desktop 正确解析并传递给 WSL2 中的 dockerd。
VS Code 连 WSL2 开发时的路径陷阱
用 VS Code 的 “Remote-WSL” 插件打开项目，看似在 WSL 环境里编辑，但只要项目实际位于 \wsl$ 下，终端里执行 docker build 仍会走 9P 协议，性能不改善。真正有效的做法是：
- 项目放在
D:projectsmyapp（Windows 原生路径） - VS Code 用 “Remote-WSL” 打开，它会自动将
D:映射为/mnt/d/，你在终端里 cd 到/mnt/d/projects/myapp是安全的 - 此时
docker build -f /mnt/d/projects/myapp/Dockerfile /mnt/d/projects/myapp实际仍由 Docker Desktop 解析为 Windows 路径，走的是高效路径，不是 9P
关键点在于：Docker Desktop 只认 Windows 路径；VS Code Remote-WSL 只是帮你把 Windows 路径“翻译”成 WSL 可见形式，底层并未改变数据存放位置。
最易被忽略的一点：即使你把项目放对了位置，如果 .dockerignore 里写了 **/node_modules，而 node_modules 在 \wsl$ 下，Docker 会因无法 stat 文件而跳过忽略逻辑，导致整个 WSL home 目录被塞进构建上下文——瞬间构建变慢十倍。务必确认所有参与构建的路径都在 Windows 侧。
