composer install 报“maximum function nesting level”是因 xdebug 默认嵌套限制 256 被其依赖解析器触发，非 composer 自身问题；应禁用 xdebug 而非调高限制，避免插件冗余与环境不一致。
为什么 composer install 会报 “Maximum function nesting level”？
这不是 Composer 自身的问题，而是 Xdebug 的递归限制被 Composer 的依赖解析器（特别是 composer/composer 内部的 AST 解析和插件加载逻辑）意外触发。Xdebug 默认的 xdebug.max_nesting_level=256 在处理大型项目（比如含 dozens 个插件、嵌套 require-dev、或使用 path repository 的 monorepo）时很容易耗尽。
临时禁用 Xdebug 是最安全的解决方式
Composer 运行时并不需要调试器——它不跑你写的业务代码，只做依赖计算、文件下载和 autoloader 生成。开着 Xdebug 反而拖慢速度、增加栈深度风险。
- 运行前加
php -d xdebug.mode=off $(which composer) install - 或者直接改 CLI 的 php.ini：
sed -i 's/^xdebug./;//' $(php --ini | grep "Loaded Configuration File" | cut -d' ' -f4)（Linux/macOS） - Mac 上用 Homebrew 安装的 PHP，常见路径是
/usr/local/etc/php/X.Y/conf.d/ext-xdebug.ini，注释掉整段即可
xdebug.max_nesting_level 调高只是掩耳盗铃
调到 512 甚至 1024 看似能过，但实际掩盖了两个问题：一是 Composer 正在加载大量插件或解析复杂 composer.json 结构（比如循环引用、冗余 repository 配置），二是你的本地开发环境和 CI 环境不一致——CI 通常没开 Xdebug，结果本地能过 CI 报错。
- 检查是否有插件在
composer.json里重复声明，比如同时用了hirak/prestissimo（已废弃）和内置 HTTP 并发 - 运行
composer show --plugins看是否加载了非必要插件（如dealerdirect/phpcodesniffer-composer-installer在纯安装阶段完全不需要） -
composer install --no-plugins可快速验证是否插件引发的嵌套爆炸
Docker 或 CI 中要彻底隔离 Xdebug
很多团队在 Dockerfile 里用 php:8.2-cli 基础镜像，但构建时顺手装了 Xdebug（比如为了本地调试），结果 composer install 在容器内失败。这类环境没法“临时关”，必须从源头剔除。
- Docker 构建阶段用多阶段：编译依赖用无 Xdebug 的纯净镜像，最后才 COPY vendor
- GitHub Actions 中避免
shivammathur/setup-php默认启用 Xdebug，显式设extensions: mbstring, gd, curl（不列 xdebug） - GitLab CI 中确认
php -m | grep xdebug返回空，而不是靠php -v看版本——后者可能仍加载了模块
composer 就会中招。 
