composer安装报错主因是镜像被项目级repositories覆盖、缓存与lock文件残留、ca证书失效、权限污染及php cli环境不匹配；需先清缓存删lock、检查repositories配置、更新ca证书、修复归属权并确认cli php路径。
Composer 安装仍报错，大概率不是 PHP 没配好，而是 Composer 自身的环境链路断在了别的环节——PHP 版本/扩展只是第一关，后面还有镜像、缓存、权限、证书、项目级配置五道坎。直接重装 PHP 或改 php.ini 通常无效。
检查 Composer 是否真在用你配的 PHP
Composer 是个 PHP 脚本，它运行时依赖的是 php 命令指向的解释器，不是你 Web 服务用的那个。很多人改了 Apache 的 php.ini，但 CLI 模式下 php -v 还是旧版本。
- 执行
php -v和which php，确认 CLI 使用的 PHP 版本和路径 - 执行
php --ini，看加载的是哪个php.ini；重点检查extension_dir下的curl.so、openssl.so、mbstring.so是否真实存在且已启用 - 如果用 Docker 或宝塔，CLI 用户（如
www或runner）可能没权限读取全局php.ini，需显式指定：php -c /etc/php/8.1/cli/php.ini composer install
镜像配置是否被项目级 repositories 覆盖
只要项目根目录 composer.json 里有 "repositories" 字段（哪怕空数组 "repositories": []），全局镜像配置 composer config -g repo.packagist 就完全失效——不是优先级低，是压根不读。
- 运行
composer config repo.packagist（无-g），输出为空或报错，说明项目级配置屏蔽了全局设置 - 删掉
composer.json中的"repositories"行，或改成"repositories": {}（空对象，非空数组） - 验证生效：运行
composer diagnose，最后一行应显示Repo packagist is private；再跑composer show packagist/support | grep homepage，URL 应含mirrors.aliyun.com
缓存与 lock 文件残留导致“换源无效”
composer.lock 里硬编码了包下载地址和哈希值，vendor/ 目录里可能存着上一次失败时截断的 ZIP 包。换镜像后不清这两样，Composer 会复用旧记录，根本不会发新请求。
- 必须执行
composer clear-cache，并确认~/.composer/cache/files/下对应包的 ZIP 文件已被清空 - 删掉项目根目录的
composer.lock和vendor/（不要只删vendor） - 加
--no-cache强制跳过本地缓存：composer install --no-cache，排除坏文件干扰
CA 证书失效导致卡在 “Loading…” 不报错
即使用了镜像，curl -v https://mirrors.aliyun.com/composer/packages.json 卡在 * TLS handshake 阶段，90% 是 PHP 的 CA 证书链过期。这不是 Composer 配置问题，是底层 HTTPS 握手失败。
- 运行
php -r "print_r(openssl_get_cert_locations());"，看default_cert_file路径是否存在且可读 - 去 https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251 下载最新
cacert.pem，存到该路径或自定义位置 - 在 CLI 使用的
php.ini中统一设两处：openssl.cafile=/path/to/cacert.pem和curl.cainfo=/path/to/cacert.pem - 改完重启终端或 reload PHP CLI 配置（如
hash -d php或新开 shell）
最容易被忽略的是项目级 repositories 字段和 composer.lock 的强绑定——它们会让所有镜像、超时、重试配置全部静默失效。先确认这两项干净，再调其他参数，否则全是白忙。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
