根本原因是PHP 8.2下opcache.enable_cli=1导致Composer自身PHAR反复预热失败，叠加默认回退官方源的30秒等待及Xdebug启用；应禁用opcache CLI、强制镜像、关闭Xdebug并验证配置生效。
PHP 8.2 环境下 Composer 加载慢，**根本原因不是 PHP 版本本身拖慢了 Composer，而是默认配置与新版 PHP 的某些机制产生了冲突，叠加国内直连 packagist.org 的网络问题，导致卡在元数据加载或依赖解析阶段**。换阿里云或华为云镜像源确实能缓解下载卡顿，但若只改源不调其他参数，仍可能卡在 Resolving dependencies 或 Loading composer repositories —— 这时候换源只是治标。
为什么换镜像源后还是卡在 Loading composer repositories？
因为 Composer 默认会「先试官方源，超时再 fallback 到镜像」。PHP 8.2 下 DNS 解析或 TLS 握手更严格，packagist.org 响应慢或中断时，Composer 会默默等满 30 秒才切镜像，整个过程不可见、不可跳过。
- 执行
composer config -g repos.packagist false彻底禁用官方源回退，强制只走镜像 - 确认镜像地址有效：阿里云用
https://mirrors.aliyun.com/composer/；华为云用https://mirrors.huaweicloud.com/composer/（注意末尾斜杠） - 避免在项目级
composer.json中写"repositories"覆盖全局配置——它优先级更高，容易引入已下线的私有源 - 运行
composer config -g --list | grep repo验证实际生效的源是否为你设的镜像
PHP 8.2 + Composer 2.x 下最易被忽略的性能陷阱
PHP 8.2 默认启用 opcache.enable_cli=1，这本意是加速 CLI 脚本，但对 Composer 反而有害：它会让 Composer 自身的 PHAR 文件反复尝试预热失败，触发大量文件 stat 和重编译。
- 临时关闭：用
php -d opcache.enable_cli=0 /usr/bin/composer install - 检查是否启用了
xdebug：PHP 8.2 下 xdebug.mode=debug 或 develop 会让 Composer 慢 5–10 倍，执行前加-d zend_extension= -d xdebug.mode=off -
apcu扩展若已装但没配apcu.enable_cli=1，CLI 下完全不生效，白装 - 确保
memory_limit不是 -1（无限制），某些 PHP 8.2 + APCu 组合下会导致 GC 频繁，反而更卡
阿里云/华为云镜像源配置后仍慢的验证步骤
别假设镜像“一定生效”，要逐层确认流量是否真走了镜像：
立即学习“PHP免费学习笔记（深入）”；
- 加
-vvv参数跑一次：composer install -vvv 2>&1 | grep "GET https"，看请求 URL 是不是你的镜像地址 - 如果出现
GET https://packagist.org/packages.json，说明repos.packagist false没生效，或被项目composer.json覆盖 - 华为云镜像偶尔同步延迟，可对比
curl -I https://mirrors.huaweicloud.com/composer/packages.json返回的Last-Modified是否在 24 小时内 - 临时禁用所有插件和自定义脚本：
composer install --no-plugins --no-scripts --no-dev，排除干扰项
真正卡住的地方，往往藏在「你以为已经关掉」的配置里：比如 CI 环境中 Dockerfile 写了 ENV COMPOSER_NO_DEV=0，导致 --no-dev 失效；或者 auth.json 里残留了失效 token，让 Composer 在每个包下载前都做一次无响应的认证请求。这些细节比换源更关键，也更难排查。
