答案是config.platform.php硬编码覆盖真实PHP版本导致依赖解析错误；Composer优先读取该配置而非php -v输出，若不一致需删除或修正platform块并执行composer update --lock。
根本不是中文环境的问题，是 config.platform.php 硬编码或 require.php 版本声明与真实 PHP 版本不一致，导致 Composer 解析依赖时“看错人”。
composer show --platform 为什么显示的 PHP 版本和 php -v 不一样
Composer 不读你终端里 php -v 的输出，它优先查 composer.json 里的 "config": {"platform": {"php": "7.4.33"}}。这个配置一旦存在，就覆盖所有环境判断——哪怕你装的是 PHP 8.5.5，它也按 7.4.33 拉包。
- 运行
composer show --platform，第一行就是它当前“认定”的 PHP 版本 - 如果输出和
php -v对不上，99% 是composer.json里写了硬编码的platform.php - 删掉整个
"platform": {...}块，或者改成匹配你真实版本的值（如"php": "8.5.5"） - 改完必须立刻执行
composer update --lock，否则composer.lock还记着旧平台逻辑
require.php 和 config.platform.php 谁说了算
两者共存时，require.php 是铁律，config.platform.php 是软覆盖。如果你在 require 里写了 "php": "^8.1"，但本地是 PHP 7.4，加了 platform 也没用，照样报错。
-
require.php决定哪些包版本能进依赖树——它是硬门槛 -
config.platform.php只影响“选哪个版本”，前提是require.php已放行 - 想用
platform模拟高版本部署环境，必须先确保require.php没锁死低版本（比如删掉或改成"php": "^7.4 || ^8.1"） - 团队协作中，
require.php应写成项目真实支持的最小版本范围，而不是开发机版本
composer install 卡在 “Resolving dependencies” 怎么快速定位
这不是网络慢，是 Composer 在暴力穷举所有 PHP 版本 + 包版本组合。常见于 require-dev 里混进了高版本要求的工具（比如 phpunit/phpunit:^10 要求 PHP 8.1+），而主项目只要 PHP 7.4。
立即学习“PHP免费学习笔记（深入）”；
- 先跑
composer update --dry-run -v，看日志末尾是否反复出现Trying php 7.4.0 → backtracking → Trying php 8.0.0 - 执行
composer show --tree | grep -A3 -B3 "phpunit"或类似命令，揪出require-dev引入的高门槛包 - 临时注释掉
require-dev整块，再试composer install—— 如果成功，问题就出在这里 - 确认后，要么降级该 dev 包（如用
phpunit/phpunit": "^9.6"），要么把require-dev拆到单独的composer.json中管理
为什么 --ignore-platform-reqs 装完就炸
它跳过校验，但不解决语法兼容性。PHP 解析器在 require 类文件时，直接遇到 readonly、enum 或 match 就崩，根本不是运行时报错，而是加载阶段 ParseError。
-
composer install --ignore-platform-reqs可能装进一堆 PHP 8.1+ 语法的类，但你的 PHP 7.4 根本 parse 不了 - 错误信息常是
ParseError: syntax error, unexpected token "readonly"，而不是Class not found - 别用它长期绕过，只在调试时加
--ignore-platform-reqs=php（注意等号后指定具体项） - 真正安全的临时方案是显式调用目标 PHP 二进制：
/usr/bin/php8.2 /usr/local/bin/composer install
最易被忽略的点：vendor/autoload.php 加载成功 ≠ 项目能跑。很多包在 class 定义里就用了高版本语法，PHP 解析器在第一次 require 时就挂了，连 autoloader 都没机会报错。
