代码必须放在wsl2原生文件系统（如~/projects）而非/mnt/c下，否则因virtiofs跨ntfs-ext4三层抽象、defender扫描及inode变更不可见，导致docker性能严重下降。
代码放在 /mnt/c 下跑 Docker，性能必然差——这不是配置没调好，而是路径选错了。
为什么挂载 Windows 路径会导致严重性能下降
WSL2 的文件系统桥接层（VirtioFS）对 /mnt/c 这类跨设备路径的 IO 处理有固有延迟：小文件 stat、open、readdir 等元数据操作耗时是原生 EXT4 的 3–5 倍；大量 node_modules 或 Python site-packages 加载时，这种放大效应直接拖垮启动和热重载速度。
根本问题不在 Docker，而在路径归属：Docker Desktop + WSL2 后端的容器运行在 Linux 环境里，却被迫频繁穿越 Windows NTFS → VirtioFS → EXT4 三层抽象。
- 编辑器保存文件触发 inode 替换，单文件挂载无法感知变更，导致“改了不生效”
-
/mnt/c/Users/xxx/project路径下即使启用 VirtioFS 缓存，也无法绕过底层驱动转发开销 - Windows Defender 实时扫描会拦截
/mnt/c下的文件访问，进一步加剧延迟
必须把代码移到 WSL2 原生文件系统
这是唯一能达成接近原生性能的做法。不是“建议”，是硬性前提。
操作步骤很简单：
- 在 WSL2 发行版中创建项目目录，例如
~/projects/myapp - 用
git clone或cp -r把代码复制进去（不要用 Windows 资源管理器拖拽） - 确保 Docker Desktop 设置 > Resources > WSL Integration 中已勾选该发行版
- 启动容器时使用
-v /home/youruser/projects/myapp:/app挂载
验证是否生效：进容器执行 df -T /app，输出应为 ext4，而非 9p 或 virtiofs。
同步文件共享（SyncFS）只适用于特定场景
同步文件共享功能在 2026 年仍不适用于 /mnt/c 路径，且仅在 Docker Desktop 原生 VM 后端（非 WSL2）中可用。它对 WSL2 用户基本无效，强行开启反而增加同步代理开销。
如果你坚持要用 Windows 文件夹开发（比如依赖 IDE 的 Windows 插件），可尝试：
- 在共享根目录下创建
.syncignore，排除node_modules、.git、dist等目录 - 改用
--mount type=bind,consistency=delegated（仅限 Linux 宿主，WSL2 不支持该选项） - 接受折损：这类场景下，性能上限由 VirtioFS 缓存策略决定，
virtiofsCacheSize=2GB在.wslconfig中设置后有一定改善
BuildKit 缓存和磁盘 IO 冲突要单独隔离
默认 BuildKit 缓存写入 WSL2 根分区（/var/lib/docker/buildkit），而你的项目代码又放在 /home，两者共用同一块虚拟磁盘 VHDX。当同时进行构建和文件读写时，IO 队列争抢会导致卡顿。
解决方法是在 /etc/docker/daemon.json 中显式指定缓存路径：
{
"builder": {
"cache-path": "/mnt/wsl/docker-cache/buildkit"
}
}
这个 /mnt/wsl/docker-cache 必须是独立挂载的 VHDX 卷（通过 wsl --mount 添加），不能是 /mnt/c 或 WSL2 自动挂载的任何路径。
复杂点在于：一旦你把项目挪到 WSL2 原生路径，就必须同步处理 BuildKit、镜像存储、日志卷三者的物理位置分离——否则“变慢”只是从代码加载转移到了构建阶段。
