必须用项目级repositories配置+显式PHP路径调用，否则composer install会拉错包、生成不兼容vendor目录；全局镜像不绑定PHP运行时，且被项目级repositories屏蔽，无法校验php版本约束。
全局镜像配置在多 PHP 版本下完全无效，必须用项目级 repositories 配置 + 显式 PHP 路径调用，否则 composer install 会拉错包、生成不兼容的 vendor/ 目录。
为什么 composer config -g repo.packagist 在多版本 PHP 下反而坏事
全局镜像只改源地址，不绑定 PHP 运行时。你有 php@7.4 和 php@8.2 并存时，composer install 实际调用哪个 php，取决于 $PATH 顺序或 alias 封装脚本——而这些和镜像无关。更危险的是：
- 项目里若已存在
repositories字段，它会直接屏蔽全局镜像，导致你以为配了却没生效 - CI/CD 中不同 job 使用不同 PHP 镜像，但共用同一份缓存的
composer.lock，镜像地址和 PHP 兼容性全错位 - 全局镜像无法校验
"php": "^8.2"是否被满足，哪怕拉到了包，也可能含match表达式，在 PHP 7.4 下直接ParseError
项目级镜像怎么写才真正生效
项目级配置是唯一能随代码提交、构建时自动生效、且优先级高于全局的方式。但格式极其敏感，错一个逗号就失效：
- 必须把镜像对象放在
repositories数组首位，且{"packagist.org": false}是独立对象，不是字段值 - 正确写法（注意末尾
/、括号、逗号）：{ "repositories": [ { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" }, {"packagist.org": false} ] } - 错误写法包括：
"repositories": {"packagist": {}}（对象而非数组）、漏掉{"packagist.org": false}、URL 少末尾/、键名写成repos.packagist - 改完后必须删掉
vendor/和composer.lock，再跑composer install——update不会重读镜像配置
COMPOSER_PHP 环境变量为什么经常不生效
COMPOSER_PHP 是 Composer 官方支持的运行时 PHP 路径覆盖方式，但它只影响 Composer 自身执行逻辑（比如 autoload 生成、scripts 中的 php 命令），不控制 scripts 里显式写的 php xxx.php，也不改变 php -v 输出：
立即学习“PHP免费学习笔记（深入）”；
- 写成
export COMPOSER_PHP=/usr/bin/php8.2后再单独跑composer install—— 某些 shell（尤其是非交互式环境如 CI）不会继承该变量 - 在
composer.json的scripts里写"test": "php tests/run.php"—— 这里的php不走COMPOSER_PHP，必须写成"test": "/usr/bin/php8.2 tests/run.php" - 用了
sudo composer install——sudo默认不传环境变量，COMPOSER_PHP丢失 - 可靠写法：直接用目标 PHP 路径调用
composer.phar，例如/usr/bin/php8.2 /path/to/composer.phar install
切换 PHP 版本后，为什么删了 vendor 还报错
因为冲突根源不在缓存，而在环境不一致或约束没对齐。每次切换 PHP CLI 版本后，必须删掉 vendor/ 和 composer.lock，再重新 composer install —— 否则生成的 vendor/autoload_static.php 会因反射行为、语法支持、扩展加载顺序等差异，在运行时报 ParseError 或类未定义：
- PHP 8.2 生成的 autoload 文件可能跳过 PHP 7.4 已废弃的魔术方法注册
- opcache.enable_cli 开关状态会影响类定义缓存，导致 autoload 映射错乱
-
config.platform.php只影响依赖解析，不改变实际运行环境；它不能让match()在 PHP 7.4 下突然可用
