Composer install 报“Too many open files”是因解压、扫描、并行下载导致文件描述符超系统默认限制（如 ulimit -n 1024）；临时修复用 ulimit -n 65536，永久生效需配置 shell 配置文件、CI 脚本、systemd 或 macOS launchd。
为什么 composer install 会报 “Too many open files”？
这不是 Composer 本身写错了，而是它在解压大量 tar.gz 包、扫描 vendor 目录、并行下载时，短时间内打开了太多文件描述符（file descriptors），超出了系统默认限制。Linux 默认 ulimit -n 通常是 1024，而一个中等规模项目依赖展开后轻松突破 2000+ 句柄。
怎么快速验证和临时修复？
先确认当前限制是否真卡住了：
- 运行
ulimit -n看输出值（比如 1024） - 执行
composer install --no-progress，如果错误复现，基本可锁定 - 临时提上限：运行
ulimit -n 65536再试 —— 这步不改系统配置，只对当前 shell 有效
注意：这个值不能无脑设太高，65536 是常见安全上限，再高可能触发内核限制或被 systemd 拦截。
如何永久生效（避免每次重开终端都输 ulimit）？
关键不是改 Composer，而是让 shell 启动时自动加载更高限制。不同场景路径不同：
- 普通用户：把
ulimit -n 65536加到~/.bashrc或~/.zshrc末尾（用 zsh 就改后者） - CI/CD 环境（如 GitHub Actions）：在 job 步骤开头加
shell: bash -c 'ulimit -n 65536 && ...' - systemd 服务（如自建 Composer 部署脚本）：需在 service 文件里加
LimitNOFILE=65536，仅靠ulimit不生效
别漏掉：macOS 的 launchd 有独立限制，得配 /etc/launchd.conf 或 per-user plist，否则 ulimit 命令无效。
还有哪些地方会悄悄吃掉文件描述符？
Composer 不是唯一源头。这些共存问题会让“Too many open files”更难定位：
- IDE（如 PHPStorm）开启大项目索引时，本身就在后台打开成百上千个文件
- 同一台机器跑着 Docker，每个容器默认共享宿主机的
ulimit，但容器内没显式设置也会继承低值 -
composer dump-autoload -o在大型项目中会扫描全部 PHP 文件，比install更“贪吃”句柄
真正麻烦的是：错误信息里从不告诉你哪个进程占满了句柄。遇到反复出错，先 lsof -u $USER | wc -l 看总量，再按进程名过滤，比瞎调 ulimit 有用得多。
