“Your requirements could not be resolved”不是锁文件损坏，而是本地PHP版本低于require.php或config.platform.php要求，或缺失mbstring/xml/curl等扩展；应运行php -v、php -m | grep mbstring、composer show --platform比对环境，并用composer why-not定位阻塞包。
composer install 报 “Your requirements could not be resolved” 先别动 lock 文件
这不是锁文件坏了，而是测试环境和 composer.json 声明不匹配。最常见的是：php -v 版本低于 config.platform.php 或 require.php 要求；或者漏装了 mbstring、xml、curl 这类扩展。
快速验证方法：
- 运行
php -v和php -m | grep mbstring，确认 PHP 版本和扩展都到位 - 执行
composer show --platform，比对输出是否和你本地真实环境一致 - 如果报错末尾出现
don't install vendor/package:version，立刻跑composer why-not vendor/package:version—— 输出最后一行是你根声明，往上每行的(required by)就是卡点
测试环境要复现生产行为？别用 composer update，用 --dry-run + --with
测试环境常需要验证某个包升级后是否兼容，但又不想全量更新破坏当前状态。这时候 composer update 是高危操作，而 --dry-run 和 --with 才是安全探针。
例如想试 guzzlehttp/guzzle:^7.5 是否能装上：
-
composer require guzzlehttp/guzzle:^7.5 --dry-run：不改任何文件，只告诉你“能不能解出来” - 如果能过，再执行
composer require guzzlehttp/guzzle:^7.5 --with-dependencies：只更新它和直系依赖，避免意外拉低其他包 - 错误写法：
composer update "guzzlehttp/guzzle:^7.5"—— 引号 +^会让 Composer 自己找“最新兼容版”，不是你要的7.5.x
CI 测试失败时，vendor/ 和 composer.lock 必须一起清
CI 环境里报 hash verification failed 或 package not found，90% 是元数据过期或镜像不同步，不是代码问题。删 vendor/ 单独没用，必须三件套同步清理：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 删掉
vendor/和composer.lock - 切回官方源：
composer config -g repo.packagist https://repo.packagist.org - 再跑
composer install -v（加-v看详细过程，方便定位卡在哪）
注意：如果项目配了私有仓库，且只托管部分包，记得在 repositories 里显式加 "canonical": false，否则它会拦住 Packagist 查找，导致“明明有新版却装不上”。
require-dev 是隐形冲突源，别忽略
很多测试失败其实来自 require-dev：比如 phpunit/phpunit 锁死 sebastian/exporter，间接拖住 symfony/console；或者 laravel/sanctum 要求 illuminate/support ^10.0，而你主项目还在 Laravel 9。
查真实依赖结构，别信 composer.json 里的“愿望清单”：
-
composer show --tree显示的是vendor/和composer.lock的真实快照 -
composer show --tree | grep "symfony/console"看它被谁引入、锁在哪个版本 -
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"确认是不是某条路径在强制降级
真正难处理的，永远是那些没出现在根 require 里、却通过 require-dev 悄悄改写整个依赖树的包。
