wsl2中composer性能瓶颈源于/mnt/c路径的drvfs文件系统，应将项目移至wsl2原生ext4路径（如~/my-project），并确保ide、cache及全局bin均使用该路径。
WSL2 默认挂载 windows 文件系统太慢
WSL2 的 /mnt/c 是通过 DrvFs 挂载的 Windows NTFS 分区，所有文件操作都要跨内核桥接，composer install 时大量小文件读写（比如 vendor 解压、autoloader 生成）会卡在 I/O 上，实测比原生 linux 慢 3–5 倍。
根本原因不是 Composer 本身，而是 WSL2 对 Windows 文件系统的访问机制。只要项目目录放在 /mnt/c/... 下，再怎么调 composer.json 都救不回来。
- ✅ 正确做法：把项目移到 WSL2 原生 ext4 文件系统下，比如
~/my-project或/home/username/my-project - ⚠️ 注意：git clone、
composer create-project等操作也得在 WSL2 路径里执行，否则又会拉回 DrvFs - ❌ 不要试图用
wsl.conf的automount选项优化/mnt/c—— 它只控制挂载行为，不改变底层性能瓶颈
composer install 卡在 “Loading composer repositories”
这通常不是网络问题，而是 WSL2 在 DrvFs 路径下解析 composer.lock 或扫描 vendor/ 时反复 stat 大量文件，触发了 DrvFs 的路径翻译开销。现象是 CPU 占用低、磁盘活动高、长时间无响应。
- ✅ 运行前先确认当前路径：
pwd输出必须是/home/...开头，不是/mnt/c/... - ✅ 清理残留：如果之前已在
/mnt/c下跑过，删掉vendor/和composer.lock，再切到 WSL2 原生路径重装 - ✅ 关闭 Windows 杀毒软件实时扫描（尤其 McAfee、Defender 的“受控文件夹访问”），它会在 DrvFs 上造成严重阻塞
如何让 phpstorm / VS Code 与 WSL2 原生路径协同工作
IDE 默认打开的是 Windows 路径，但 Composer 必须在 WSL2 原生路径运行，二者错位就会反复出错。关键不是配置 IDE 的终端 Shell，而是统一工作区根路径。
- ✅ PhpStorm：新建项目时选 “New project in WSL”，或右键项目 → “Reload project from WSL”
- ✅ VS Code：用 Remote – WSL 扩展打开文件夹，确保窗口左下角显示 “WSL: ubuntu”（或你装的发行版），且资源管理器路径是
wsl$Ubuntuhome... - ⚠️ 切记：不要在 Windows 资源管理器里双击 .php 文件用 Code 打开——那走的是 Windows 本地路径，终端也默认启动 PowerShell/CMD
- ✅ 验证方式：在 IDE 内置终端里执行
pwd && uname -r，输出应为 WSL2 路径 + 带microsoft字样的内核版本
cache 目录放哪里才真正生效
Composer 默认 cache 在 ~/.composer/cache，这个路径在 WSL2 里是 ext4，没问题。但如果你手动改过 COMPOSER_CACHE_DIR 指向 /mnt/c/Users/xxx/AppData/Local/Composer，那 cache 反而成了性能拖累——每次命中都要跨文件系统校验。
- ✅ 查看当前 cache 位置：
composer config --global cache-dir - ✅ 强制设回 WSL2 原生路径：
composer config --global cache-dir ~/.composer/cache - ✅ 如果用了
composer global require，确保全局 bin 也在 WSL2 路径：composer config --global bin-dir ~/.composer/vendor/bin
WSL2 下 Composer 的性能瓶颈几乎全在文件系统边界上，而不是 PHP 或网络。一旦路径落到 /mnt/c，所有优化都只是给瓶颈贴创可贴。最省事的办法，就是永远别让它落进去。