Composer self-update 仅更新自身二进制，不解决依赖冲突；升级后报错主因是v3更严解析策略、PHP≥8.0要求、lock文件哈希校验增强及conflict提前剪枝。

composer self-update 本身不解决依赖冲突，它只更新 Composer 自身二进制；升级后反而可能暴露或加剧原有冲突——尤其是跨主版本（如 v2 → v3）或 PHP 环境变化时。

为什么升级 Composer 后 composer update 突然报错？

Composer v3 默认启用更严格的依赖解析策略，且要求 PHP ≥ 8.0；v2.5+ 开始默认禁用 minimum-stability: dev，而旧项目常依赖 dev-main 分支。常见现象：

• Conclusion: don't install laravel/framework v10.32.0 —— 不是包不存在，而是约束链里某处锁死了低版本
• The lock file does not contain required hash —— v3 对 composer.lock 的签名校验更严，旧 lock 文件需重生成
• PHP 7.4 环境下成功运行 composer self-update --3，但后续 composer install 直接 fatal error —— v3 语法不兼容旧 PHP

composer update 卡住或死循环时该怎么做？

这不是 Composer 坏了，是它在反复回溯尝试满足所有 require、conflict 和 replace 约束。别删 vendor/ 硬来：

• 先跑 composer update --dry-run，看最后几行卡在哪条依赖路径上（注意 “Resolving dependencies” 阶段的输出）
• 用 composer why-not vendor/package:^x.y 定位阻断源，比如 composer why-not guzzlehttp/guzzle:^8.0
• 检查 composer.lock 里实际安装的版本：composer show guzzlehttp/guzzle，再看它的 require 列表是否和你的其他包冲突
• 临时放宽约束：在 composer.json 加 "minimum-stability": "dev" + "prefer-stable": true，仅用于诊断

升级到 v3 后 composer install 报 hash 错误怎么办？

v3 引入了更严格的 lock 文件完整性校验，旧 lock 文件里的哈希值不再被接受。这不是缓存问题，也不能跳过：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 必须执行 composer update --lock 重生成 lock 文件（不改依赖版本，只刷新哈希和元数据）
• 如果项目用了自定义 repo 或私有包，确保它们的 dist URL 和 source 类型仍有效；v3 对 dist 包的 checksum 验证更严格
• 不要用 --ignore-platform-reqs 绕过，它不会修复 hash 错误，只会掩盖更深层的平台不匹配

升级后发现某些包“突然不见了”或自动降级？

v3 默认启用 default-branch 检测，且对 conflict 字段执行更早、更彻底的剪枝。容易被忽略的点：

• 检查你自己的私有包是否写了 "conflict": {"laravel/framework": ">=11.0"} —— 即使没 require L11，只要某个间接依赖拉进了 L11 的候选版本，整个解析就会失败
• 某些包在 v3 下被自动替换为 polyfill（如 symfony/polyfill-mbstring 替代 ext-mbstring），但若你代码里硬调用了 mb_*() 函数而没装扩展，运行时才报错
• composer show --outdated 输出里带 (major) 的包，大概率要手动 composer require vendor/package:^x.0 逐个处理，不能靠全量 update

最易被忽略的是：升级 Composer 只是换了个解析器，不是重写依赖图。所有冲突都早已存在，只是旧版本没报、或报得不够早。真正要动的是 composer.json 里的约束，不是 Composer 本体。