Composer 不会自动检测 PHP 版本，仅依赖当前 CLI 环境版本并缓存结果；报错源于旧缓存与新环境冲突，需手动执行 composer clear-cache 和 composer update --with-all-dependencies 重校验依赖兼容性。
Composer 不会自动检测项目使用的 PHP 版本——它只读取当前运行 composer 命令时所用的 PHP CLI 环境版本，且默认缓存该信息，不会在每次命令中重新探测。你看到的“PHP 版本不匹配”报错，往往不是 Composer 主动发现了版本变化，而是旧缓存 + 新环境触发了冲突。
composer show --platform 只反映当前 CLI 环境
这个命令输出的是执行时 PHP 解释器的真实版本和已启用扩展，例如：
php version: 8.2.12 ext-curl: 8.2.12 ext-mbstring: 8.2.12 ext-openssl: 8.2.12
但它不做任何“检测”动作，只是把 php -v 和 php -m 的结果格式化输出。如果你切了 PHP 版本但没重启终端或刷新 shell 环境，这里显示的仍是旧版本。
- 常见误判：在 Docker 或 CI 中换 PHP 镜像后仍看到旧版本，大概率是 shell 缓存了
php命令路径，用hash -d php或新开 shell 解决 - 它不读
composer.json中的"php": "^8.1"，也不校验该约束是否满足——那是在install/update阶段做的 - 若扩展缺失（如缺
ext-gd），这里会直接显示ext-gd: false，比猜错误原因快得多
composer install/update 时才真正校验 platform 约束
Composer 只有在解析依赖时，才会把 composer.json 里的 "php" 和 "ext-*" 要求，跟当前 show --platform 输出的实际环境做比对。失败时典型报错是：
立即学习“PHP免费学习笔记（深入）”；
Your requirements could not be resolved to an installable set of packages.
但注意：这个校验默认被跳过——只要 composer.lock 存在且没改 composer.json 的 require，composer install 就直接按 lock 文件装，连 platform 检查都省了。
- 强制触发校验：加
--ignore-platform-reqs是绕过，不是启用；真要重检，得先composer clear-cache，再composer update --with-all-dependencies -
composer.json中的"config": {"platform": {"php": "7.4.0"}}是反向操作：它让 Composer 假装运行在 PHP 7.4，即使你本地是 8.2 —— 这用于兼容性预检，不是自动检测 - 扩展名必须拼写完全一致，
ext-iconv≠iconv，ext-pdo_mysql≠pdo_mysql
没有“自动检测”，只有“显式声明 + 显式触发”
Composer 没有后台服务、没有定时扫描、也没有钩子监听 php -v 变化。所谓“检测”，全靠你主动调用命令，并确保环境干净。
- 升级 PHP 后必做三件事：
php -v确认 CLI 版本 →composer clear-cache清掉旧 platform 快照 →composer update --with-all-dependencies重算整个依赖图 - CI/CD 中不要依赖“某次 install 成功就代表兼容”，必须对每个目标 PHP 版本单独跑
composer install+ 运行测试，因为lock文件本身不记录平台信息 - 如果项目要支持多 PHP 版本，
composer.json的"php"字段应写成宽泛范围（如"^7.4 || ^8.0 || ^8.1 || ^8.2"），而不是锁死单个版本，否则update时容易卡住
最易忽略的一点：composer.lock 文件里从不保存 PHP 版本。这意味着同一份 lock 文件，在 PHP 7.4 和 8.2 下都能 install 成功——只要里面所有包恰好都兼容两者。但这种“侥幸通过”无法保证，也不能替代主动验证。
