镜像源仅加速元数据下载，不解决php版本、扩展或锁文件约束错位问题；报错“requires php ^8.1”本质是当前cli的php -v版本（如7.4.33）不满足composer.json中声明的php约束，需校准php -v、config.platform和composer.lock三者一致性。
镜像源本身不解决版本号匹配问题，它只加速包元数据下载；真正卡住安装的，从来不是网络，而是 PHP 版本、扩展声明、锁文件约束这三者之间的错位。
为什么换镜像后 still “requires php ^8.1” 报错
报错 Your PHP version (7.4.33) does not satisfy that requirement 说明 Composer 正在用你当前 CLI 的 php -v 版本去比对 composer.json 中某个包的 "php": "^8.1" 声明。镜像只是把 Packagist 的 packages.json 下得更快，但校验逻辑完全不变。
- 确认真实 PHP 版本：
php -v（注意不是which php或 IDE 内置终端缓存） - 检查是否被
config.platform.php覆盖：composer config --list | grep platform - 镜像生效验证：
composer config -g repo.packagist必须输出类似https://mirrors.aliyun.com/composer/
composer update 显示 “Nothing to install or update” 却装不上新版
这不是镜像没生效，而是 Composer 在用本地缓存的 packages.json 元数据算依赖——默认 15 分钟不过期，Packagist 上已有 v3.6.0，你本地还按 v3.5.0 算。
- 优先执行：
composer update --refresh（Composer ≥2.5 支持，只清元数据缓存，不删已下载 ZIP） - 老版本可用：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 别用
composer clear-cache：它会连 dist 包一起删，下次 install 又要重下，反而更慢
本地能装、CI 报 ext-gd 缺失，镜像改不了这事
composer install 默认跳过扩展校验——只要 composer.lock 存在，它就直接按锁文件装包，不查 ext-gd 是否真有。镜像再快，也掩盖不了运行时崩掉的风险。
- 必须在
composer.json的config.platform段显式声明："ext-gd": "8.1.0"（写具体版本，别写true或空字符串） - 该配置需提交进 Git，否则新人
composer install仍按本地真实环境解析 -
--ignore-platform-reqs是临时止痛药：加了它，可能装入带match表达式的包，而你本地是 PHP 8.0，运行即ParseError
删 composer.lock 后问题还在，说明根源不在缓存
删锁文件会让 Composer 从头解析整个依赖图，但若 php -v 还是 7.4，composer.json 里仍写着 "php": "^8.1"，那报错会原样重现。镜像再快，也救不了约束错位。
- 先定位阻塞点：
composer why-not guzzlehttp/guzzle:^7.5（它会打印哪条依赖链卡住了） - 升级 PHP 后，建议删掉
composer.lock中的platform字段再composer install，避免沿用旧兼容策略 - CI 脚本中务必前置
php -v打日志，否则你根本不知道底层在用几
镜像解决的是“下载慢”，不是“装不上”；真正要动的，是 php -v、composer.json 的 require.php 和 config.platform、以及 composer.lock 的生成时机——这三处任一错位，换十次镜像都没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
