禁用 xdebug 可使 composer install 在 resolving dependencies 阶段提速 5–10 倍，因其全程劫持 php opcode 解析和函数调用栈，而 composer 依赖求解属 cpu 密集型操作；临时禁用应执行 php -d zend_extension= -d xdebug.mode=off $(which composer) install，确保 php -d zend_extension= -d xdebug.mode=off -m | grep xdebug 输出为空。
禁用 Xdebug 是 Composer 性能优化里见效最快、成本最低的操作——它能让 composer install 在 Resolving dependencies 阶段提速 5–10 倍，不是“有点快”，而是从卡住到秒出。
为什么 Xdebug 会让 Composer 变慢？
Xdebug 会全程劫持 PHP 的 opcode 解析和函数调用栈，而 Composer 的依赖求解（尤其是 Resolving dependencies）本质是大量字符串匹配、版本约束计算和 JSON 解析——全是 CPU 密集型操作，Xdebug 的调试钩子直接放大每一步开销。
常见现象：composer install 卡在 “Resolving dependencies…” 超过 2 分钟，top 显示 PHP 进程吃满 CPU，但 strace -c 发现系统调用极少，基本就是 Xdebug 在拖后腿。
-
php -m | grep xdebug输出非空，说明已加载 - 即使没启用
xdebug.mode=debug，只要扩展加载了，默认就会触发 profiling 和 tracing 的基础逻辑 - PHP 8.2+ 中 Xdebug 4.x 对 Composer 2.7+ 的兼容性更差，慢得更明显
怎么临时禁用 Xdebug 执行 Composer？
别改 php.ini，也别重启 PHP-FPM——直接在命令行绕过：
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer install
或者更稳妥的写法（兼容不同安装路径）：
php -d zend_extension= -d xdebug.mode=off $(which composer) install
-
zend_extension=是清空已加载的扩展路径，比zend_extension=0更可靠 -
xdebug.mode=off确保不意外进入开发模式 - 这个命令只影响当前进程，不影响其他 PHP 服务
CI/CD 流水线里必须固化这一步
很多构建失败或超时，根本原因就是 Jenkins/GitLab Runner 默认启用了 Xdebug（尤其 Docker 镜像里带 Xdebug 的 dev 版本）。
- 流水线脚本里不要写
composer install，要写完整命令：php -d zend_extension= -d xdebug.mode=off composer install --no-dev --prefer-dist -o - 如果用的是自定义 PHP 镜像，建议构建时就移除 Xdebug：
docker-php-ext-remove xdebug - 检查
php -i | grep xdebug输出是否为空——这是 CI 环境上线前的必检项
别被“Xdebug 已关闭”骗了
有些环境显示 xdebug.mode=off，但 zend_extension 仍加载着，Composer 依然慢。真正有效的判断标准只有一个：
执行 php -d zend_extension= -d xdebug.mode=off -m | grep xdebug，输出必须为空。
容易被忽略的是：某些 IDE（如 PHPStorm）会在 CLI 启动时自动注入 Xdebug 配置，即使你手动关了，它也可能悄悄加回来——所以 CI 环境务必用显式参数覆盖。
