如何解决Composer在处理超大vendor目录时的文件系统性能瓶颈？ (inode与NFS)

根本原因是NFSv3默认不缓存stat()导致遍历vendor下数万php文件时产生大量网络延迟；推荐将vendor移至本地磁盘后符号链接，或使用–no-autoloader跳过 autoload 生成。

为什么 composer install 在 NFS 上卡在 “Generating autoload files”？

根本原因不是 Composer 本身慢，而是 vendor/ 目录下成千上万个 PHP 文件触发了 NFS 的 inode 查找与 stat 调用风暴。NFSv3 默认不缓存 stat() 结果，每次生成 autoloader 都要遍历所有 .php 文件并逐个 stat()，而 NFS 的 round-trip 延迟（哪怕只有 1–2ms）乘以 50,000+ 文件，就会卡住几十秒甚至几分钟。

• NFS 客户端未启用 noac（关闭属性缓存）时反而更糟——它会强制每次检查 mtime/size
• composer dump-autoload --optimize 会加剧问题，因为它要读取全部类文件来构建 classmap
• PHP 的 opcache.revalidate_freq=0 无法缓解此问题，因为瓶颈在文件系统层，不在 OPCache

绕过 NFS：把 vendor 移到本地磁盘再符号链接

这是最稳定、零配置改动的方案。Composer 本身不关心 vendor 是真实目录还是符号链接，只要路径可写且能解析即可。

• 在本地磁盘创建 /tmp/myproject-vendor（或挂载的 SSD 分区）
• 运行 COMPOSER_VENDOR_DIR=/tmp/myproject-vendor composer install
• 安装完成后，删掉原 vendor/，执行 ln -s /tmp/myproject-vendor vendor
• 后续 composer update 仍需指定 COMPOSER_VENDOR_DIR，否则会重建本地目录

注意：如果项目用了 psr-4 自动加载且依赖 vendor/autoload.php 的相对路径，该方案完全兼容；但若硬编码了 vendor/ 绝对路径（比如某些部署脚本），需同步修正。

禁用 autoload 生成阶段的文件扫描（仅限开发环境）

如果你只是想快速跑通 CI 或本地启动，不真正在意自动加载性能，可以跳过 autoload 生成：

composer install --no-autoloader composer dump-autoload --classmap-authoritative --no-dev

• --no-autoloader 跳过 install 后的 autoload 生成，避免卡住
• dump-autoload --classmap-authoritative 强制只用 classmap，不再运行 scandir() 扫描 vendor/ 下所有包的源码目录
• 缺点：无法支持动态加载未声明的类（如某些插件机制），且 --no-dev 会剔除 require-dev 中的 autoloader 条目

调整 NFS 挂载参数（需运维配合）

如果必须把 vendor/ 留在 NFS 上（例如共享构建环境），关键不是调大 rsize/wsize，而是控制元数据缓存行为：

• 服务端确保 export 选项含 no_root_squash 和 async（降低写延迟）
• 客户端挂载时加：nfsvers=4.1,hard,intr,rsize=1048576,wsize=1048576,acregmin=60,acregmax=180,acdirmin=30,acdirmax=60
• 其中 acregmin/max 控制文件属性（mtime/size）缓存时间，acdirmin/max 控制目录内容缓存——这两项对 scandir() 和 stat() 性能影响最大
• 切勿使用 noac：它禁用所有属性缓存，会让问题恶化

实际效果取决于 NFS 服务器负载和网络 RTT；在高延迟（>5ms）或高并发场景下，即使调优后仍可能比本地盘慢 3–5 倍。

真正棘手的从来不是“怎么让 NFS 快起来”，而是“哪些步骤其实根本不需要碰 NFS”。比如 vendor/ 在构建阶段生成后，运行时只需读取——那构建放本地、运行时只 rsync autoload.php 和 classmap.php 过去，往往比调优挂载参数更可靠。