生产环境 Composer 报“Your requirements could not be resolved”说明依赖约束无解，根本原因在于 composer.lock 与 composer.json 脱节或平台环境不匹配；应立即执行 composer update --lock 重建合法锁文件，而非 install 或手动修改 lock。
生产环境出现 Composer 版本冲突，说明当前 composer.lock 与线上运行状态已脱节，或新部署的 composer.json 引入了不兼容约束——此时绝不能直接 composer install 或 composer update，必须先验证、再重建。
为什么线上报错“Your requirements could not be resolved”不是网络问题
这个报错是 Composer 在本地或 CI 构建阶段就该暴露的约束无解信号。一旦它出现在生产环境，通常意味着：
- CI 构建时用了
--ignore-platform-reqs或--no-scripts绕过检查，但实际运行时 PHP 版本、扩展缺失或类加载失败才暴露 - 团队提交了修改后的
composer.json，却没同步提交更新后的composer.lock（Git 冲突后手动删了 lock 文件） - 运维手动在服务器上执行了
composer update，导致vendor/与composer.lock不一致，而后续composer install因哈希校验失败静默跳过部分包
关键判断点：composer install 报错且提示 content-hash mismatch 或 Package xyz has a mismatched hash，就证明 lock 文件已失效，不能再信它。
线上紧急修复：只用 composer update --lock，别碰 vendor/
这是唯一能在不中断服务前提下重置依赖契约的操作。它不读旧 lock，只按当前 composer.json 重新生成合法 lock 文件，且不改动 vendor/ 目录。
- 先确认线上
composer.json是最新且无冲突的（比如从 Git tag 检出，或对比git show HEAD:composer.json） - 运行
composer update --lock—— 预期输出应为Lock file operations: 0 installs, 0 updates, 0 removals；如果出现大量Updating xxx，说明composer.json还没对齐，得先拉代码再试 - 生成新
composer.lock后，立刻git add composer.lock && git commit -m "fix: rebuild lock for prod"，确保下次部署可复现 - 切勿执行
rm -rf vendor/ && composer install：这会绕过所有版本契约，可能装入未测试过的子依赖组合
本地复现并定位真实冲突源，用 composer why-not 而非猜
线上报错往往只显示结论（如 don't install laravel/framework:10.40.0），但真正卡住的可能是间接依赖。必须在本地完全复现环境后排查：
- 用和线上一致的 PHP 版本、扩展开启状态（尤其是
ext-zip、ext-opcache）启动容器或虚拟环境 - 执行
composer why-not vendor/package:version（把报错里提到的包名和版本填进去），看输出最后一行是不是你的根项目your-project dev-main requires ... - 重点盯输出中带
conflict with的行，以及反复出现的中间包（如guzzlehttp/guzzle、symfony/console）——它们才是真正的交集断点 - 若
why-not输出里有require-dev包（如phpunit/phpunit），说明测试工具污染了生产依赖树，应改用composer install --no-dev部署
锁文件重建后仍报 Class not found？检查间接依赖是否被意外降级
composer update --lock 只保证 lock 文件合法，不保证所有子依赖版本与之前一致。尤其当旧 lock 锁的是某个包的 v2.8.1，而新 lock 因约束放宽选了 v2.5.0，就可能触发运行时错误。
- 对比前后
composer.lock的content-hash和具体包版本：用git diff查composer.lock，聚焦报错类所在的包及其require列表 - 查 Packagist 确认该包各版本的
require声明是否有变化（比如 v2.5.0 移除了对psr/log的依赖，而你的代码直用了它） - 若确认是子依赖降级导致，可在
composer.json中显式锁定关键包："psr/log": "1.1.4"，再跑一次composer update --lock - 永远不要手动编辑
composer.lock：字段顺序、缩进、空行都参与哈希计算，Git 合并残留的会直接让 JSON 解析失败
最易被忽略的点：线上环境的 composer.lock 往往是多人协作中“合并冲突后删标记”的产物，表面能解析，实则哈希已失效——composer update --lock 是唯一能彻底重置它的操作，但它不解决根本约束矛盾，只提供干净起点。
