Composer依赖冲突是约束无交集导致的“算不出解”，应先用composer why-not定位拒绝链、结合--dry-run验证，聚焦Root requirements与冲突包版本交集，禁用require-dev干扰，不删composer.lock。
Composer 依赖冲突不是“装不上”，而是“算不出解”——它已经穷举过所有组合，发现你的 require、conflict、PHP 版本、require-dev 约束之间没有交集。
为什么 composer require 一执行就报错“Your requirements could not be resolved”
这不是网络问题，也不是权限问题，是 Composer 在解析阶段确认：当前所有约束条件（包括你没注意的 require-dev 包）合起来，根本不存在一个合法的版本组合。
- 常见诱因：某个
require-dev包（比如phpunit/phpunit）要求sebastian/exporter ^4.0，而主框架要求^5.0，它们互锁 -
composer require vendor/package:2.3.0失败时，别急着换版本——先跑composer why-not vendor/package:2.3.0 - 这个命令输出是“拒绝链”，必须从最后一行（通常是你的根项目）倒着读，才能定位真正卡死的节点
- 如果输出为空或只显示
nothing，说明2.3.0这个版本压根没发布过，不是冲突，是版本不存在
composer update 到底该不该全量更新
全量 composer update 是最危险的操作之一：它会重算整个依赖树，可能把 symfony/event-dispatcher 从 v6.x 回退到 v5.4，只因为某个旧版 monolog/monolog 的依赖路径更“易满足”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 优先用
composer update vendor/package --with-dependencies，它只重算目标包及其直系依赖，不碰phpunit或laravel/pint这类无关项 - 必须显式写包名，不能带
^、~或引号，例如：composer update monolog/monolog --with-dependencies - 加
--with-dependencies是关键——不加的话，Composer 常直接拒绝执行，报 “无法满足要求” - 升级后立刻
git diff composer.lock，确认只有预期包和其直系依赖被改；多改一个symfony/polyfill-*都可能埋隐患
如何安全干预版本选择，而不是靠猜
Composer 不会自动“退一步”，你得明确告诉它边界在哪里。盲目删 composer.lock 或 vendor/ 只会让线索丢失，让问题更难复现。
- 想锁定或降级某个包，先用
composer require vendor/package:1.27.0 --no-update——--no-update很关键，它只改composer.json，不触发重算 - 改完后手动运行
composer update vendor/package，让 Composer 仅针对这个包重新解析 - 如果仍冲突，说明其他包也强绑了互斥版本，此时用
composer show -t看完整依赖树，找真正“卡死”的节点 - 检查
^1.2.3和~1.2.3的差异：^允许1.x内任意小版本，~只允许1.2.x补丁更新——写宽松前，先查对方是否真做语义化发布
为什么 composer install 有时比 update 更有效
团队协作中拉新代码后报 Root requires X but Y is installed，大概率是别人提交了新 composer.json 却漏提 composer.lock。这时 composer install（不带 update）才是正确动作。
-
composer install严格按composer.lock安装，跳过所有重算逻辑，适合环境同步 - 若不确定 lock 是否可信，先跑
composer install --dry-run，它会预演冲突点，明确告诉你哪一行约束断了 -
composer.lock是当前已验证可行的依赖快照，不是障碍；删它等于扔掉唯一线索 - 本地 PHP 版本或扩展不同？直接
composer install就能过——它不看composer.json的platform配置，只认 lock 文件里的实际安装记录
最常被忽略的点：所有 require-dev 包都参与依赖解析，哪怕你只在测试里用；conflict 规则全局生效，不看它是不是你的直接依赖；私有源必须配 "packagist": false，否则 Packagist.org 会插队兜底。
