根本原因是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 生成：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
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 过去，往往比调优挂载参数更可靠。
