先定位不兼容包，再升级或临时绕过；可用 composer why-not php:8.0 查冲突，加 config.platform.php 或 --ignore-platform-req=php 临时跳过校验，但运行时仍可能报错。
Composer install 报 ParseError 或 TypeError 怎么办
PHP 8 引入了严格类型检查和新语法（如联合类型、mixed、static 返回类型），很多旧版包的 composer.json 声明或源码本身不兼容。常见现象是运行 composer install 或 composer update 时直接报错退出，甚至卡在解析阶段。
核心不是 Composer 本身不支持 PHP 8——它早支持了——而是你锁死的依赖版本没适配。关键动作是：先确认错误源头是哪个包，再决定升级、替换或临时绕过。
- 用
composer why-not php:8.0查哪些包明确声明不支持 PHP 8（看其require.php字段） - 加
-v参数重试安装，错误栈里往上翻，找到第一个崩溃的包名（常是monolog/monolog、symfony/console等老版本） - 别急着删
vendor或composer.lock——先定位，再干预
如何让 Composer 跳过不兼容包的 PHP 版本校验
仅限临时调试或无法升级依赖的紧急场景。Composer 默认会严格校验 platform.php 和包的 require.php 是否匹配，但可以欺骗它。
原理是告诉 Composer：“当前环境是 PHP 8，但我允许装那些声明只支持 PHP 7.x 的包”。这不是修复，是掩耳盗铃，后续运行时仍可能崩。
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 在
composer.json顶层加字段："config": { "platform": { "php": "8.0.0" } } - 或者命令行强制指定：
composer install --ignore-platform-req=php - ⚠️ 注意：
--ignore-platform-req=php会跳过所有 PHP 版本检查，包括扩展（如ext-mbstring），容易漏掉真正需要的扩展
升级依赖时 Composer 卡在 Resolving dependencies 不动
这是 PHP 8 下最隐蔽的坑：某些旧包（尤其 v1.x 的 guzzlehttp/guzzle、ramsey/uuid）的 composer.json 用了已废弃的约束写法（如 ^7.0 || ^8.0），导致 Composer 8+ 的依赖解析器陷入无限回溯。
根本原因是语义化版本解析逻辑变更，不是性能问题。等几分钟没反应，基本就是这个原因。
- 用
composer update --dry-run -v观察最后解析到哪个包就卡住 - 手动在
composer.json中排除可疑包："conflict": { "guzzlehttp/guzzle": "，再试 - 更稳妥的是锁定目标包的已知兼容版本，例如：
"guzzlehttp/guzzle": "^7.2"，然后composer update guzzlehttp/guzzle
为什么 composer update 后部分功能异常但没报错
PHP 8 的 TypeError 默认不被 catch，而很多老代码依赖 catch (Exception $e) 捕获一切错误。结果就是：调用一个返回 int|null 的函数，传了字符串进去，PHP 8 直接抛 TypeError，但你的 try-catch 没抓到，程序静默失败或返回空值。
这和 Composer 无关，但升级后才暴露——因为旧 PHP 版本只是警告或忽略。
- 检查日志是否出现未捕获的
TypeError（不是Exception） - 在
php.ini加error_log = /tmp/php8-errors.log并设log_errors = On，复现操作后查日志 - 对关键函数调用补一层
is_int()、is_string()校验，别信文档里的“默认返回 null”
PHP 8 的类型系统是双刃剑：严了，但严得不声不响。Composer 只管装包，不管运行时怎么崩。最麻烦的从来不是装不上，而是装上了却在某个分支里悄悄挂掉。
