composer check-platform-reqs 报错即环境不达标，该命令仅校验当前PHP版本与扩展是否满足composer.json中require和config.platform约束，失败时明确提示缺失扩展或版本不符，建议纳入CI部署前必检步骤。
composer check-platform-reqs 报错就说明环境不达标
这个命令是 Composer 2.0+ 引入的平台检查入口，它不装包、不改 lock，只读取 composer.json 里的 require 和 config.platform，然后比对当前 PHP 版本、已启用扩展是否满足所有依赖的约束。一旦失败，错误信息会明确指出缺哪个扩展或 PHP 版本太低——比如报 ext-intl is missing 或 php (>=8.2) required, but 8.1.25 present。
常见误操作是跳过这步直接跑 composer install，结果卡在中间或后续运行时报函数不存在。建议把它加入 CI 部署前的必检步骤，用生产环境的 PHP 进程执行：
- 确保
php -v输出的版本和php -m列出的扩展与项目要求一致 - 如果本地开发用 Docker，CI 用宿主机 PHP，二者输出必须一致，否则
check-platform-reqs通过 ≠ 线上能跑 - 不要依赖
--ignore-platform-reqs临时绕过——它只是掩盖问题，不是解决问题
config.platform.php 设置后仍装错包？先清缓存
你在 composer.json 的 config.platform 里写了 "php": "8.3"，但 composer update 装出来的包还是只兼容 PHP 8.1，大概率是 Composer 缓存了旧的平台解析结果。它不会因为 config 改了就自动失效缓存。
必须手动清除：
- 运行
composer clear-cache—— 清掉本地已下载的 dist 包和元数据 - 再执行
composer update --with-all-dependencies，强制重算整个依赖图 - 注意：仅
composer update不够，它默认只更新顶层 require，间接依赖仍锁在旧版本里
升级 Composer 自身后，composer install 失败怎么办
Composer 2.5+ 移除了 self-update 命令，升级靠重装。如果你从 1.x 或 2.4.x 升到 2.9.x，composer install 可能直接报 ParseError: syntax error, unexpected Attribute——这不是项目代码问题，是 Composer 自身用了 PHP 8.0+ 语法，而你还在用 PHP 7.4。
验证和修复步骤：
- 运行
php -v确认真实 PHP 版本；若低于 8.0，Composer 2.5+ 无法运行 - 运行
composer --version看是否真升级成功（别信which composer显示的路径） - 如果升级后命令异常，检查
composer.phar文件权限，尤其在 /usr/local/bin 下软链接指向只读位置时会静默失败
为什么 composer prohibits 查不到真正拦路的包
composer prohibits vendor/package 是排查冲突的好工具，但它只显示“当前 lock 文件里哪些已装包阻止了目标包安装”，不反映平台级限制（如 PHP 版本、扩展缺失）。比如你装 guzzlehttp/guzzle:^8.0 失败，prohibits 可能返回空，但实际拦路的是 ext-curl 没启用。
更完整的排查链是：
- 先跑
composer check-platform-reqs排除环境问题 - 再跑
composer prohibits vendor/package看是否有版本冲突 - 最后用
composer show vendor/package查它的require字段，确认它自己有没有硬性平台依赖
平台兼容性不是“一次配好就完事”的事，它是 PHP 版本、扩展状态、Composer 版本、lock 文件解析结果四者实时耦合的结果。任何一环变了，都得重新走一遍检查闭环，而不是只盯着 composer.json 改几行。
