composer报错“your requirements could not be resolved”是依赖解析失败，主因是本地php版本、扩展或lib库与composer.json/platform配置/lock文件环境不匹配，需用composer why-not定位真实阻断链，而非重装或删vendor。
同一台机器上跑多个 PHP 项目，根本不需要“全局切换 PHP 版本”或“手动删 vendor”，关键在于让每个项目的 composer.lock 在它自己的运行时环境里能被正确解析。
为什么 composer install 在 A 机器成功、B 机器报 Your requirements could not be resolved
这不是网络问题，也不是权限问题，而是 Composer 解析依赖时把本地 PHP 版本、已启用扩展（如 ext-intl）、lib-* 库版本全算进约束条件。常见诱因：
-
composer.json里写了"config": {"platform": {"php": "8.1.0"}}，但你本地是 PHP 8.2 —— Composer 会按声明的平台去匹配包，不是按真实环境 - 某人本地装了
ext-gd，另一人没装，而某个包在require里写了"ext-gd": "*"，install 就直接失败 -
composer.lock是用 PHP 8.1 +--with-all-dependencies生成的，但有人用 PHP 7.4 执行install，SAT 求解器策略不同，卡在Resolving dependencies - Git 合并时破坏了
composer.lock：比如.gitattributes强制 text 合并，导致 JSON 字段错位或丢失
用 composer why-not 定位跨项目阻断源，别猜
报错末尾出现 Conclusion: don't install laravel/framework:v10.32.0，不代表这个版本不能用，只说明当前环境里有东西在联合封杀它。立刻执行：
composer why-not laravel/framework:v10.32.0
它会输出真实阻断链，例如：
myapp/core dev-main requires php ^8.1<br>laravel/framework v10.32.0 requires php ^8.1
或者：
myapp/legacy-sdk v2.4 requires guzzlehttp/guzzle ^6.5<br>laravel/framework v10.32.0 requires guzzlehttp/guzzle ^7.2
如果输出为空，加 -v 再试：composer why-not laravel/framework:v10.32.0 -v，看是否来自 platform 配置或 conflict 字段。
多项目并行时，composer.lock 同步前必须验证的三件事
团队共享或跨机器复用 composer.lock 前，确保它能在所有目标环境中稳定解析：
- 所有人运行
composer show --platform，核对php、ext-*、lib-*输出是否一致；不一致就先统一 Dockerfile 或.php-version - 运行
composer update --dry-run，观察是否卡在Resolving dependencies（超 2 分钟基本可判定为解析瓶颈） - 检查
composer.lock文件头部的platform字段是否与当前项目实际部署环境一致，尤其注意php和关键扩展如ext-mbstring
私有组件和 require-dev 是隐形冲突高发区
模块化开发中，冲突常来自你控制的私有包或测试工具，而非主框架：
- 主项目用
laravel/framework: ^10.0，但某个私有 SDK 的composer.json里写"require": {"laravel/framework": "^9.0"}—— 这个 SDK 必须先升级 -
require-dev里的orchestra/testbench: ^7.0会悄悄拉入laravel/framework: ^9.0，跟主项目冲突；换成^10.0或移出require-dev到单独的测试容器里 - 自己写的包加了
"conflict": {"php": ">=8.3"}，但项目还没升到 8.3，却仍报错 ——conflict是全局生效的，哪怕没直接 require，只要其他包间接拉进来就会触发
真正难处理的从来不是版本号本身，而是那些没显式写在 composer.json 里、却通过 platform、conflict、replace 或扩展检测悄悄参与约束计算的隐性条件。
