Composer 运行慢的常见原因是启用了 xdebug 扩展，它会全程介入 PHP 函数调用和栈追踪，大幅拖慢依赖解析与加载；应通过临时禁用、切换配置文件等方式按需关闭 xdebug，并配合 --no-scripts 等参数进一步提速。
为什么 Composer 运行慢？xdebug 是常见元凶
Composer 在启用 xdebug 扩展时，安装或更新依赖会明显变慢——有时慢 3–10 倍。这是因为 xdebug 会全程介入 PHP 的所有函数调用、变量解析和栈追踪，而 Composer 的依赖解析、类加载、脚本执行等环节恰好大量触发这些行为。
关键判断：如果你的 composer install 或 composer update 卡在 Loading composer repositories 或 Resolving dependencies 阶段很久，且 php -v 显示已加载 xdebug，那基本就是它。
禁用 xdebug 的三种可靠方式（按推荐顺序）
不要改 php.ini 全局关掉——开发时可能需要 xdebug 调试。应按需临时禁用：
git摸鱼周报自动化
下载
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。
- 运行 Composer 时临时关闭：
php -d zend_extension= -d extension= composer.phar install
（适用于 PHP 8+；zend_extension=清空值可卸载 xdebug，extension=清空常规扩展） - 用
php -n（no php.ini 模式），再显式加载必要扩展：php -n -d extension=mbstring.so -d extension=openssl.so composer.phar install
注意：必须补上 Composer 依赖的基础扩展，否则报错如Class 'Phar' not found - 切换 CLI 的 php.ini 配置文件（推荐长期使用）：
复制一份无 xdebug 的配置：cp /etc/php/8.2/cli/php.ini /etc/php/8.2/cli/php-cli-no-xdebug.ini
编辑该文件，删掉或注释掉zend_extension=xdebug.so行；然后运行：php -c /etc/php/8.2/cli/php-cli-no-xdebug.ini composer.phar update
其他不影响调试但显著提速的 Composer 配置项
禁用 xdebug 后，再加几条配置，能进一步减少 I/O 和网络等待：
- 强制跳过平台检查（避免反复验证 PHP/扩展版本）：
composer install --ignore-platform-reqs（仅限可信环境） - 关闭脚本执行（如不需要 post-install-cmd）：
composer install --no-scripts - 禁用插件（某些插件如
hirak/prestissimo已过时，新版 Composer 内置并行下载，反而冲突）：composer install --no-plugins - 设置超时和重试（防止卡死在网络请求）：
composer config --global process-timeout 300composer config --global github-protocols https
验证是否生效：别只看时间，要看实际行为
提速后仍要确认 xdebug 真的没加载：
- 运行：
php -d zend_extension= -m | grep -i xdebug
输出为空才表示成功卸载 - 对比耗时差异：
先记下time php -m | grep -i xdebug是否有输出；再跑一次time php -d zend_extension= composer.phar install --no-scripts --no-plugins；两次时间差应明显（尤其在大型项目中） - 注意陷阱：Docker 环境里，宿主机禁用了 xdebug，但容器内 PHP 仍可能加载；务必进容器执行
php -m确认
最易被忽略的是「多 PHP 版本共存」场景：你改了 php8.2 的配置，但 Composer 实际调用的是 php8.1 ——务必用 which php 和 php -v 双重确认当前 CLI 使用的 PHP 路径与版本。
