Composer 2.2.4+ 完全支持 PHP 8，问题主因是依赖包不兼容或 platform 配置缺失；必须升级 Composer、显式配置 "config": {"platform": {"php": "8.2.10"}}，并验证运行时异常。
Composer 本身从 2.2+ 就完全支持 PHP 8，问题几乎全出在依赖包和配置上——不是 Composer 跑不起来，而是它装出来的包在 PHP 8 下运行时报 Fatal error 或 TypeError。
确认 Composer 版本是否 ≥ 2.2.4
Composer 1.x 在 PHP 8 下会直接崩溃，报 ParseError: syntax error, unexpected token "string"。这不是警告，是解析器层面不兼容。
- 运行
composer --version，输出含Composer version 1.就必须升级 - 推荐用官方安装命令覆盖重装：
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && php composer-setup.php --install-dir=/usr/local/bin --filename=composer - 旧版插件（如
hirak/prestissimo）可能卡死composer update，升级后先禁用测试
强制锁定 platform.php 版本
"config": {"platform": {"php": "8.2.10"}} 这行配置不是可选项，是必须项。它让 Composer 忽略你本地 php -v 的结果，只按目标环境选包。
- 别写
"php": "^8.2"或"~8.2"—— Composer 不识别这种写法，等于没设 - 小版本写全更稳（比如
"8.2.10"而非"8.2"），避免因 patch 版本差异导致子依赖错配 - 删掉该配置后执行
composer update，很可能降级一堆包，且不会提示你
排查卡死或无限回溯的依赖包
运行 composer update -v 卡住不动、CPU 占满、等几分钟没反应？大概率是某个老包的 composer.json 用了废弃约束（如 "^7.0 || ^8.0"），触发 Composer 2.5+ 的新解析器回溯爆炸。
立即学习“PHP免费学习笔记（深入）”；
- 加
--dry-run -v观察最后解析到哪个包就停住，常见元凶：guzzlehttp/guzzlev6、ramsey/uuidv3、monolog/monologv1 - 定位后，显式指定已知兼容版本：
"guzzlehttp/guzzle": "^7.2"，再运行composer update guzzlehttp/guzzle - 别用
--ignore-platform-req=php硬顶——它跳过所有 PHP 校验，包括ext-mbstring这类真实依赖，后续运行时仍崩
验证 autoload 是否真兼容 PHP 8 语法
即使 composer install 成功，某些类用了 PHP 8 新特性（如构造函数属性提升 public function __construct(public string $name)），而 Composer 旧版（2.2.0–2.2.3）生成的 vendor/autoload_classmap.php 会反射失败，报 Class not found。
- 升级 Composer 到 2.5+ 可解决此问题
- 临时验证：删掉
vendor/autoload_classmap.php，改用 PSR-4 自动加载（确保composer.json中 autoload 配置正确） - CI 流程中建议加一行检查：
php -l vendor/autoload.php，能过不代表类能实例化，但至少语法合法
最易被忽略的是：platform 配置只影响依赖解析，不保证运行时安全。哪怕所有包都装上了，仍要跑实际业务逻辑测试，重点捕获 TypeError、ValueError 和 UnhandledMatchError 这类 PHP 8 新增异常。
