/mnt/c/下composer install慢是因为ntfs通过drvfs挂载导致高频小文件i/o需跨内核转发，延迟飙升5–10倍；应将项目移至wsl2原生ext4路径（如~/project），并设阿里云镜像、清缓存、加--no-dev等参数优化。

为什么/mnt/c/下composer install慢得像在编译Linux内核

因为Windows文件系统（NTFS）通过/mnt/c/挂载到WSL2后，所有文件操作都要经过跨内核的翻译层（drvfs），inode、权限、符号链接、atime等行为全被模拟。而composer install这种高频小文件读写场景会直接触发大量syscall转发，I/O延迟飙升5–10倍是常态。

项目必须放在WSL原生ext4分区上

永远不要把项目放在/mnt/c/Users/xxx/project或任何/mnt/下路径中运行composer install或composer update。

• 把项目移到WSL2原生文件系统里，比如~/project、/home/username/project或/opt/project
• 执行df -T .确认当前目录所在分区的Type列：显示ext4或zfs→安全；显示9p或drvfs→危险
• 别误用/tmp：它默认是tmpfs，速度快但重启丢失；composer install会失败，因为vendor需要持久化且支持硬链接

WSL里设阿里云镜像不是可选项，是必做项

并发下载再快，也救不了每个请求都卡在DNS解析或TLS握手——换源+清缓存才是提速前提。

windows-shell-syntax

在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……

下载

• 设阿里云镜像：composer config -g repo.packagist https://mirrors.aliyun.com/composer/
• 验证是否生效：composer config -g repo.packagist输出必须是完整URL，不能是null或空值
• 换源后务必清缓存：composer clear-cache，否则旧元数据仍在偷偷走packagist.org
• 已停更的源（如https://packagist.phpcomposer.com）会返回404，千万别用

生产构建命令漏掉任意一个参数，就白优化了

composer install在CI/CD中多花30%–60%时间，往往就差这四个参数。

• --no-dev：跳过require-dev下所有包（如phpunit），省掉30–60%解析时间
• --prefer-dist：强制走ZIP包而非Git克隆，避开SSH认证、分支切换等开销
• --optimize-autoloader：生成静态类映射，减少运行时文件扫描（注意：--optimize已废弃）
• --classmap-authoritative：告诉autoloader“查不到就真没有”，跳过PSR-4 fallback；但仅应在生产或CI中使用，开发环境误用会导致新增类不被识别

最容易被忽略的是：--no-dev和--optimize-autoloader必须组合使用。只加--no-dev却漏掉-o，autoload生成阶段仍可能爆内存。