根本原因是WSL通过9P协议挂载Windows文件系统导致I/O性能极差，应将项目移至WSL本地ext4路径（如~/projects/），再禁用Windows Defender对ext4.vhdx的扫描，最后优化composer配置。
为什么WSL中composer install特别慢
根本原因是WSL默认通过9P协议挂载Windows文件系统（如/mnt/c/），而composer大量读写vendor/、composer.lock和临时缓存时，9P的元数据操作和小文件I/O性能极差——实测比原生Linux慢5–10倍。不是网络问题，也不是PHP配置问题，是文件系统层瓶颈。
把项目移到WSL本地文件系统（必须）
这是最有效、最直接的优化动作。所有后续优化都建立在此基础上，否则其他调整收效甚微。
- 不要把项目放在
/mnt/c/Users/xxx/project这类路径下 - 把项目复制或初始化到WSL内部路径，例如
~/projects/myapp（对应/home/yourname/projects/myapp） - 确认路径归属：运行
df -h .，输出中Filesystem列应为ext4或zfs，而非9p - 如果用VS Code Remote-WSL打开项目，请确保工作区路径是
~/...而非/mnt/c/...
禁用WIndows Defender实时扫描（关键但常被忽略）
Windows Defender会深度扫描WSL2的虚拟磁盘文件（ext4.vhdx），尤其在composer install解压数百个包时触发高频IO+扫描冲突，导致卡顿甚至超时。
- 打开Windows安全中心 → “病毒和威胁防护” → “管理设置” → “添加或删除排除项”
- 添加排除路径：
C:\Users\{user}\AppData\Local\Packages\{distro-name}\LocalState\ext4.vhdx - 也可用PowerShell一次性添加（以管理员身份运行）：
Set-MpPreference -ExclusionPath "C:\Users\YourName\AppData\Local\Packages\Ubuntu_123456789\LocalState\ext4.vhdx"
- 注意：排除的是
.vhdx文件本身，不是整个LocalState目录
调整composer配置提升执行效率
在WSL本地路径前提下，这些配置能进一步减少等待时间：
- 启用并行下载：
composer config -g process-timeout 3600+composer config -g use-include-path true - 强制使用HTTPS镜像源（国内用户）：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（或阿里云、腾讯云镜像） - 关闭xdebug（若启用）：
php -d xdebug.mode=off $(which composer) install，因为xdebug会显著拖慢autoload生成 - 避免
--no-dev误用：仅在部署时加，开发阶段保留dev-dependencies可避免反复重装
真正卡住你的，往往不是composer命令本身，而是它在错误的文件系统上反复open/close成百上千个小文件。先挪路径，再关杀软，最后调参数——顺序不能反。很多“优化指南”跳过第一步，结果后面全白忙。
