wsl2 中 /mnt/c/ 下 composer install 极慢，因 ntfs 通过 drvfs 挂载导致高频小文件 i/o 延迟飙升 5–10 倍；应将项目移至 wsl2 原生 ext4 分区（如 ~/project），并禁用自动挂载与 windows 互操作以优化性能。
为什么 WSL2 的 /mnt/c/ 下 composer install 慢得像在编译 Linux 内核
因为 Windows 文件系统（NTFS）通过 /mnt/c/ 挂载到 WSL2 后，所有文件操作都要经过跨内核的翻译层（drvfs），inode、权限、符号链接、atime 等行为全被模拟，composer install 这种高频小文件读写场景会直接触发大量 syscall 转发，I/O 延迟飙升 5–10 倍是常态。
实操建议：
- 永远不要把项目放在
/mnt/c/Users/xxx/project或任何/mnt/下路径中运行composer install或composer update - 把项目移到 WSL2 原生文件系统里，比如
~/project、/home/username/project或/opt/project - 如果必须从 Windows 编辑（例如用 VS Code），用 WSL Remote 扩展打开
~/project，而非打开//wsl$/Ubuntu/home/username/project—— 后者本质还是走网络共享，同样慢
如何确认当前项目是否在 WSL 原生文件系统上
执行 df -T .，看当前目录所在分区的 Type 列：
- 显示
ext4或zfs→ 安全，是原生文件系统 - 显示
9p或drvfs→ 危险，正在走 Windows 文件桥接，性能受损 -
findmnt -T .也能快速验证挂载源，重点看TARGET是否为/（即根分区）
注意：/tmp 在 WSL2 中默认是 tmpfs，速度极快，但重启丢失；别误以为它适合放 vendor —— composer install 会失败，因为 vendor 需要持久化且支持硬链接
WSL1 和 WSL2 对 composer 性能的影响差异
WSL1 没有真实 Linux 内核，文件系统是直接映射，/mnt/c/ 下的 I/O 延迟比 WSL2 低不少，但代价是不兼容部分 Linux 行为（如 inotify 监听失效，导致 Laravel Mix/HMR 失效）。
所以不能简单说“WSL1 更快就换回去”：
- 如果你只跑
composer install+php artisan serve（无文件监听），WSL1 的/mnt/c/可能勉强可用 - 但只要涉及
symfony/flex插件、phpstan扫描、或任何依赖inotify/epoll的工具，必须用 WSL2 + 原生路径 - WSL2 的内存和 CPU 开销更大，但对 composer 来说，I/O 瓶颈远大于 CPU，所以“慢在磁盘，不在核数”
额外提速：禁用 WSL2 的多余挂载和 Windows 集成
WSL2 默认自动挂载所有 Windows 驱动器（/mnt/d, /mnt/e…），并启用 Windows 互操作（code, explorer.exe 调用）。这些虽方便，但会增加初始化开销和潜在的文件系统干扰。
优化方法：
- 编辑
/etc/wsl.conf（若不存在则新建），加入：[automount] enabled = false options = "metadata,uid=1000,gid=1000,umask=022"
→ 关闭自动挂载，避免/mnt/下一堆空目录拖慢find或ls - 在 Windows 的 PowerShell 中执行：
wsl --shutdown，再重启 WSL，让配置生效 - 不需要 Windows GUI 工具时，在
/etc/wsl.conf加上：[interop] enabled = false
→ 减少进程间通信开销（对 composer 本身影响小，但减少后台干扰）
改完之后，composer install 不会变魔法般快 10 倍，但能稳定在原生 ext4 的预期水平 —— 也就是你该有的速度。真正的瓶颈从来不在 PHP 或 Composer，而在你敲下回车时，光标停在哪条路径上。
