根本原因是WSL 2中/mnt/c/路径通过DrvFs驱动挂载，跨VM文件操作延迟高，导致Composer大量小文件操作卡顿；必须将项目放在/home/username/等原生Linux路径下执行。
WSL 2 中 Composer 安装或更新极慢，根本原因不是 Composer 本身，而是 Windows 与 Linux 文件系统交叉访问时的 I/O 延迟——/mnt/c/ 下的路径（即 Windows 文件）在 WSL 2 里读写性能极差，尤其涉及大量小文件操作（如 composer install 解压 vendor）。
为什么 /mnt/c/ 路径会让 Composer 变慢？
WSL 2 的虚拟机内核通过 DrvFs 驱动挂载 Windows 分区，该驱动对 POSIX 语义支持不完整，且每次文件操作（stat、open、read）都要跨 VM 边界，导致毫秒级延迟被放大成秒级卡顿。Composer 的 vendor/ 目录含数千个文件，这种开销直接体现为“卡住 10 分钟不动”。
- 典型现象：
composer install卡在Loading composer repositories with package information或Installing dependencies from lock file阶段，CPU 占用低但磁盘 I/O 持续高 - 可验证：在
/mnt/c/Users/xxx/project执行time find . -name "*.php" | wc -l，对比在~/project下执行相同命令，耗时差异常达 5–10 倍 - 注意：
/etc/wsl.conf中的automount设置无法绕过 DrvFs 性能瓶颈
必须把项目放在 WSL 2 原生文件系统中
所有 Composer 操作必须在 /home/username/ 或 /tmp/ 等 Linux 原生路径下进行，不能放在 /mnt/c/、/mnt/d/ 等挂载点下。
- 正确做法：在终端中执行
cd ~ && mkdir myproject && cd myproject
，然后运行composer create-project或git clone - Windows 端编辑器（如 VS Code）需用 Remote-WSL 插件打开
\wsl$Ubuntuhomeusernamemyproject，而非直接打开C:Usersxxxproject - 若已误在
/mnt/c/下执行了composer install，不要试图移动整个vendor/目录——先删掉它，再把项目复制到~/下重新安装
加速技巧：启用 Composer 的本地缓存和跳过平台检查
即使路径正确，WSL 2 的默认配置仍可能拖慢首次安装。以下两项设置能显著减少网络和文件扫描开销：
- 启用本地包缓存：
composer config -g cache-dir ~/.composer/cache
（确保缓存位于原生文件系统） - 跳过平台扩展检查（尤其当你不依赖
ext-*扩展时）：composer install --no-platform-checks
，避免反复调用php -m扫描模块 - 禁用 Git 钩子和脚本（开发阶段可选）：
composer install --no-scripts --no-plugins
，防止执行耗时的 post-install-cmd
别碰 Windows 文件，也别信 symlink 折中方案
有人尝试在 ~/project 中用 ln -s /mnt/c/Users/xxx/src ./src 来共享源码——这反而更慢，因为 symlink 目标仍在 DrvFs 上，每次解析都触发跨边界调用。Git 仓库同理：不要在 /mnt/c/ 初始化 repo 后用 WSL 2 的 git 操作，而应直接在 ~/ 下 git clone。
真正影响速度的从来不是 PHP 版本或镜像源，是文件落在哪块磁盘上。只要路径错，换什么镜像、加多少并发都没用。
