报错时勿删 composer.lock，应先用 composer update --dry-run -v 查冲突链，再用 composer why-not 和 prohibits 定位根本原因；刷新 lock 应用 composer update --lock，而非盲目 update 或删锁重装。
项目升级后 Composer 报“Your requirements could not be resolved”，不是 lock 文件“旧了”要刷新，而是依赖约束之间出现了不可调和的冲突；强行删 lock + install 或盲目 run composer update，反而会让问题更难定位、更难复现。
报错时别删 composer.lock，先用 --dry-run 摊开看冲突链
这个错误本质是 Composer 在告诉你：当前所有条件（composer.json、已安装包、composer.lock、PHP 版本、platform 配置）合起来，找不到一组满足全部约束的版本组合。删 composer.lock 是放弃已知可运行状态，让求解器从零瞎试。
- 运行
composer update --dry-run -v，不改任何文件，但会输出完整推理过程，末尾几行直接指出第一个断点，例如：Because guzzlehttp/guzzle[7.8.0] requires php ^7.2.5 || ^8.0, and your PHP version (8.3.0) does not satisfy that requirement - 重点盯住反复出现的包名（如
monolog/monolog、symfony/console），它们往往是冲突枢纽 - 注意 “Root requirements” 段落——它明确标出是你
composer.json里哪一行（比如"laravel/framework": "^11.0"）触发了整条链崩塌
定位拦路虎：why-not 和 prohibits 必须配合用
composer why-not 回答“为什么我装不上这个版本”，composer prohibits 直接回答“谁在禁止它”。两个命令结果精准、不绕弯，比翻 lock 文件快十倍。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查某版本为何装不上：
composer why-not laravel/framework:11.0→ 输出类似：spatie/laravel-backup v8.0.0 requires laravel/framework ^10.0 - 反向查谁锁死了某个包：
composer prohibits guzzlehttp/guzzle:^7.8→ 可能返回：aws/aws-sdk-php 3.270.0 requires guzzlehttp/guzzle ^6.5.5 - 注意：必须写全包名+版本号（如
guzzlehttp/guzzle:^7.8），只写guzzlehttp/guzzle会报[InvalidArgumentException] Package not found
强制刷新 lock 文件？只有 composer update --lock 是安全的
所谓“刷新 lock”，真实需求通常是：你改了 composer.json 里的非依赖字段（如 description、config.sort-packages），但 composer install 提示 “lock file is not up to date”。这时你要的不是重算依赖，而是重写 lock 的元数据。
-
composer update --lock（Composer 2.2+）或composer update --lock（旧版行为略有差异）是唯一安全方式：它不升级包、不联网、不重算依赖树，只根据当前vendor/目录重新生成哈希、URL、autoload 映射等字段 - 别用
composer update替代——它会升掉你没碰过的包，破坏环境一致性 - 删
composer.lock后跑composer install是危险操作：它会从头解析，可能拉入新发布的 patch 版本（如monolog/monolog从 3.5.0 升到 3.6.0），而该版本你从未测试过
手动改 lock 文件或降级 Composer 会引发隐式不一致
composer.lock 不是配置文件，是带哈希校验的结构化快照。哪怕只改错一个逗号，composer install 就可能报 Invalid argument supplied for foreach()（实际是 JSON 解析失败）。
- Composer 2.x 生成的 lock 文件含
content-hash、packages-dev分离等字段，降级到 1.x 后运行composer install会失败，因为 1.x 解析器不认识这些字段 - 若真需降级，必须先
git checkout上一个兼容的composer.lock，再composer self-update --1 - 插件不兼容（如报
Plugin X is not compatible）通常是因为其composer.json缺"composer-plugin-api": "^2.0"，优先跑composer diagnose定位，而不是动 lock
真正容易被忽略的点在于：lock 文件的“不一致”从来不是格式或时间问题，而是约束逻辑的显性暴露。它不掩盖矛盾，只把冲突摊在你面前——关键是你得用对命令去看，而不是急着删掉它来假装问题不存在。
