composer依赖冲突的本质是版本无交集，需用composer why-not倒读定位阻塞点，禁删composer.lock，升级用--with-dependencies精准控制，本地path包需注意conflict硬拦截。
Composer 依赖冲突不是“装不上”，而是它穷举完所有组合后发现没有版本交集——直接删 composer.lock 或硬加 --ignore-platform-reqs 只会让问题更难定位、更难复现。
怎么一眼看出谁在拦路？用 composer why-not 倒读最后一行
报错里只写 Conclusion: don't install laravel/sanctum:^3.0，但没说谁不让装。这时候别改 composer.json，先敲：
composer why-not laravel/sanctum:^3.0
输出会像这样：
myapp/myproject dev-main requires guzzlehttp/guzzle (^6.5)<br>laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)
关键在最后一行：它告诉你新包要什么；倒数第二行告诉你谁卡着不让它进来。必须从底往上读，才能锁定真实阻塞点。
- 如果输出为空，说明这个版本根本没发布，不是冲突，是输错了或镜像没同步
- 看到
(conflict with vendor/package >=2.0)，说明那个包自己写了conflict字段，Composer 是照章执行，不是误判 -
require-dev里的包（比如phpunit/phpunit）也参与解析，常是隐形源头
怎么定点升级而不牵连其他包？用 composer update vendor/package --with-dependencies
想升 monolog/monolog 到 3.0.0，又不想动 phpunit 或 symfony/polyfill？不能跑全量 composer update，也不能写 composer update "monolog/monolog:^3"（引号+波浪号会让 Composer 自己找最新版，可能越界）。
正确命令是：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer update monolog/monolog --with-dependencies
--with-dependencies 是关键：它只允许升 monolog/monolog 所需的最小依赖集，比如 psr/log，但不会去碰 phpunit 这类无关项。
- 不加这个参数，Composer 常直接拒绝执行，报 “无法满足要求”
- 升级后立刻
git diff composer.lock，确认只有monolog/monolog和它的直系依赖被改——多改一个symfony/polyfill-*都可能埋隐患 - 如果提示 “requires php ^8.1”，但你本地是 PHP 7.4，那不是命令问题，是环境不匹配，得先切 PHP 版本再执行
为什么不能删 composer.lock 再重装？
composer.lock 不是障碍，是当前已验证可行的依赖快照。删它等于扔掉唯一线索，重来一遍只会更难定位。
直接删锁文件再跑 composer install，会绕过所有版本契约，导致线上行为漂移：本地能跑，CI 构建或线上报 Class not found，因为间接依赖被意外降级。
-
composer.lock含content-hash校验，字段顺序、缩进、空行、platform字段都参与计算；Git 合并留下的标记会让 JSON 解析失败 - 冲突时唯一安全动作是
composer update --lock：它不读旧 lock，只按当前composer.json重算哈希与依赖，确保结构完整、子依赖一致 - 执行前必须先统一
composer.json（git checkout --theirs composer.json或手动整合），否则composer update --lock仍会大量更新包
本地包（path repository）为啥总冲突？它被当“已发布包”严格校验
你写了个本地工具包，用 path 方式引入，结果一跑就冲突，不是路径错了，是 Composer 把它当成了远程包，严格校验它 composer.json 里的 conflict、require、php 约束。
比如它写了 "conflict": {"laravel/framework": ">=11.0"}，哪怕你项目没装 L11，只要其他依赖间接拉进一个带 L11 声明的包，就直接失败。
- 确认是否加载成功：
composer config repositories看有没有你的路径条目；composer show --tree看它是否出现在依赖树里 -
composer why-not能查，但必须用它composer.json里声明的name（比如"acme/utils"），不是路径名 - 开发阶段可临时注释掉本地包的
conflict字段——它不是提示，是硬拦截，留着就等于主动拒绝自己
真正难的从来不是命令怎么敲，而是看懂 Composer 在日志末尾写的那句 Because A requires X, and B requires Y——它已经把答案写明白了，只是你得翻到最后几行，再倒着读一遍。
