大规模服务器群上禁用现场composer install，因并发文件系统调用易致nfs元数据队列过载；必须将vendor作为构建产物分发，启用--classmap-authoritative并设为只读，ansible仅负责解压、校验与权限设置。
composer install 在大规模服务器群上直接跑，会卡死不是因为网络慢，而是所有节点同时触发海量文件系统调用，尤其当 vendor/ 被挂载为共享目录或走 NFS 时，stat()、open()、read() 请求瞬间打爆元数据队列。
必须把 vendor/ 当构建产物，而非运行时共享资源。
为什么不能在目标节点上直接执行 composer install
集群里“同步 vendor”不等于“同步文件”，真正爆炸的是 PHP autoloader 运行时反复扫描目录的行为。即使你用 rsync 分发完，只要没关掉 fallback 机制，每次 class_exists() 或自动加载都会触发 scandir() —— 在 NFS 上单次扫描可能耗时数百毫秒，几百个进程并发扫，IO 就彻底堵死。
- 错误日志常见但误导性提示：
No space left on device（实际是 inode 耗尽）或failed to open stream，而df -h显示磁盘充足 -
composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative必须在 CI 构建阶段执行，不能放到 Ansible play 中现场跑 - Ansible 的
command模块调用composer install属于高危操作，等同于在生产环境手敲命令
正确分发路径：构建 → 打包 → 解压 → 只读锁定
核心原则：所有节点的 vendor/ 内容完全一致，且不依赖运行时生成或修改。
- CI 流水线中用 Docker 构建镜像：先
COPY composer.json composer.lock .，再RUN composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative，最后COPY . .—— 这样vendor/是静态层，可缓存复用 - 若不用容器，改用压缩包分发：
tar -cf - -C vendor . | ssh nodeX 'tar -xf - -C /app/vendor'，比rsync -av少 90% 的stat()调用 - 强制只读：
chmod -R a-w /app/vendor，防止任何运行时写入（包括 Composer 自动更新或插件生成缓存） - 推荐压缩格式：
zstd（tar -cf vendor.tar.zst -I zstd -C vendor .），解压速度比 gzip 快 3×，适合批量部署
Ansible 如何安全集成？只做三件事
Ansible 不负责安装依赖，只负责搬运、校验、设权。它该是“快递员”，不是“装配工”。
- 用
unarchive模块解压预构建的vendor.tar.zst，设置remote_src: true避免先下载到控制节点再分发 - 用
file模块递归设权：path: /app/vendor mode: 'a-w'，并确认state: directory - 用
community.general.archive（或自定义脚本）在 CI 侧生成类映射校验值，Ansible 用checksum模块比对vendor/composer/autoload_classmap.php是否被篡改 - 禁用全局 Composer 缓存共享：每个节点必须有独立
cache-dir，例如composer config -g cache-dir /var/cache/composer-$(hostname)，否则缓存锁会成为第二个 IO 瓶颈
最容易被忽略的点：autoloader 的 fallback 没关干净
哪怕 autoload_classmap.php 存在且非空，只要 composer.json 里没显式开启 "classmap-authoritative": true，PHP 运行时仍会 fallback 到目录扫描逻辑 —— 这个开关必须硬编码进项目配置，不能靠安装参数临时生效。
验证方式很简单：在任意节点执行 php -r "echo class_exists('Monolog\Logger') ? 'OK' : 'FALLBACK ACTIVE';"，如果返回 FALLBACK ACTIVE，说明类映射未被权威启用，IO 风暴风险仍在。
