启用Xdebug后composer install变慢的根本原因是Xdebug在每次PHP函数调用时执行额外钩子检查，尤其xdebug.mode=debug或develop时，大幅放大类加载、反射和文件I/O的毫秒级开销。
为什么启用Xdebug后composer install慢得像卡住？
根本原因不是Composer本身变慢，而是Xdebug在每次PHP函数调用时都执行额外的钩子检查（尤其是xdebug.mode=debug或develop时），而Composer依赖大量类自动加载、反射和文件I/O——这些操作天然触发高频函数调用。结果是Xdebug把毫秒级开销放大成秒级延迟。
xdebug.mode设错是最常见的性能雷区
Xdebug 3+ 引入了xdebug.mode配置项，它控制Xdebug启用哪些子系统。很多开发者直接写xdebug.mode=debug,develop甚至all，却没意识到develop会强制开启xdebug.start_with_request=yes，导致每个CLI请求都启动调试器；而debug模式下，即使没连IDE，Xdebug仍持续监听端口并准备断点。
- 开发时只运行Composer？设为
xdebug.mode=off最安全 - 需要动态启停？用环境变量临时关闭：
XDEBUG_MODE=off composer install - 必须保留覆盖率或trace？改用
xdebug.mode=coverage,profile，它们不干扰常规执行流
CLI与Web配置混用导致“关不掉”的真实原因
PHP CLI和FPM通常加载不同php.ini文件。你可能在/etc/php/*/fpm/php.ini里关了Xdebug，但composer走的是/etc/php/*/cli/php.ini——这里Xdebug仍开着。更隐蔽的是，某些Docker镜像或Homebrew PHP会把Xdebug配置单独放在conf.d/99-xdebug.ini里，且CLI目录下也有同名文件。
验证方式很简单：
php -m | grep xdebug php -i | grep "xdebug.mode"
如果输出有xdebug，再查它加载自哪个路径：
php --ini
Composer自身缓存和插件也会被Xdebug拖累
Composer 2.x 默认启用插件（如hirak/prestissimo旧版、composer-unused等），这些插件常做反射分析或远程元数据解析——全是Xdebug重灾区。同时，vendor/composer/installed.json等缓存文件的读写也会因Xdebug的文件钩子变慢。
- 临时禁用所有插件：
COMPOSER_DISABLE_PLUGINS=1 composer install - 跳过插件自动加载：
composer install --no-plugins - 清空并重建锁文件（有时Xdebug让hash计算失准）：
rm composer.lock && COMPOSER_DISABLE_PLUGINS=1 composer install
XDEBUG_MODE环境变量，并确认CLI的PHP配置独立生效。 
