composer依赖冲突本质是版本约束无交集的数学问题；必须用composer why-not定位阻断链，再通过单点更新、--with-dependencies或手动锁定中间版本解决，删vendor或lock文件反而恶化问题。
Composer依赖冲突不是“装不上”，是约束无交集的明确数学结论；解决路径很窄：必须用 composer why-not 定位封杀链，再靠单点更新或手动锁定中间版本收口，删 vendor 或 composer.lock 只会让问题更难复现。
composer why-not 是唯一靠谱的起点
报错里写的 Conclusion: don't install laravel/sanctum:^3.0 不告诉你谁在拦。而 composer why-not laravel/sanctum:^3.0 会直接输出阻断链，比如：
myapp/myproject dev-main requires guzzlehttp/guzzle (^6.5) laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)
这说明冲突根源是 guzzlehttp/guzzle 的版本范围没交集。此时别急着改 composer.json，先顺藤摸瓜：
-
composer why guzzlehttp/guzzle查它被谁拉进来（常是require-dev里的phpunit/phpunit或私有 SDK） -
composer show -t | grep guzzle看实际安装版本和是否被 lock 死 - 注意
composer depends guzzlehttp/guzzle只显示“谁用了它”，不体现版本限制，容易误判
定点更新比全量 update 更快、更安全
默认 composer update 会触发 SAT 求解器暴力遍历所有组合，尤其项目有 conflict 或 30+ 包时，可能卡在 Resolving dependencies 超过 5 分钟。真要升级 monolog/monolog 到 3.0.0，只做这一件事：
composer update monolog/monolog --with-dependencies
--with-dependencies 是关键——它只允许升级 monolog/monolog 所需的最小依赖集（如 psr/log），不会波及 laravel/framework 或 phpunit 这类无关项。几个易错点：
- 别写
composer update "monolog/monolog:^3"：引号 +^会让 Composer 去找“最新兼容版”，不一定是你想要的3.0.0 - 升级后立刻
git diff composer.lock，确认只有monolog/monolog和它的直系依赖被改 - 如果提示 PHP 版本不满足（如
monolog/monolog:3.0.0要 PHP >=8.1），那不是命令问题，是环境不匹配
手动锁定中间版本比放宽约束更可控
当两个包一个要求 "monolog/monolog": "^1.25"，另一个要求 "monolog/monolog": "^2.10"，它们语义化版本无交集。与其写 "monolog/monolog": "^1.25 || ^2.10"（等于把兼容性问题拖到运行时报错），不如去 Packagist 查哪个版本被双方都接受——比如 v2.9.3 同时出现在 A 包的 ^2.0 和 B 包的 >=2.8.0 范围里。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
这时直接在 composer.json 里写：
"monolog/monolog": "2.9.3"
再执行：
composer update monolog/monolog
这种写法绕过 SemVer 自动解析，跳过求解器瓶颈。但要注意：
- 别在
require-dev里塞和主项目冲突的包（如主项目用laravel/framework: ^10.0，就别让orchestra/testbench: ^7.0进来，它内部硬绑 Laravel 9） - 私有包若用
"my/private-package": "dev-main"，composer.lock会记 commit hash，网络波动或缓存失效可能导致下次install拉到不同 commit，引发隐式断裂 - 改完后务必跑
composer validate，确认 JSON 结构合法，再composer install --no-scripts --no-plugins快速验证 vendor 是否能还原
锁文件不一致时，优先用 --lock 修复而非重生成
composer install 报 "found x packages with version constraints that differ"，通常不是网络问题，而是 composer.lock 与当前 composer.json 约束、PHP 环境三者之间出现逻辑矛盾。最安全的修复方式是：
composer update --lock
它不做任何包升级，只根据当前 composer.json 和已安装 vendor/（如有）重新生成 composer.lock，确保二者逻辑自洽。适用场景包括：
- 刚从 Git 拉下新分支，
composer install失败，但vendor/已存在且能跑通 - 你只改了
composer.json的require版本号（如从^1.25改成^2.10），想让 lock 文件立刻反映这个变更意图 - 想验证 lock 是否真损坏：
composer update --lock --dry-run，若报错，说明composer.json存在隐式冲突（如同时 require 互斥包）
真正难搞的是 composer update --lock 也失败——这意味着冲突在更底层，比如某个包被 conflict 字段全局封杀，或 minimum-stability 设置导致可用版本被过滤。这时候得回到 composer why-not，盯住报错里那个具体被拒绝的版本，一层层剥开依赖链。
