依赖冲突本质是约束交集判断，需用composer why-not定位封杀源，倒读反向依赖链找真实冲突点，避免删锁文件或忽略平台要求。
大型项目里依赖冲突不是“能不能装上”的问题，而是“约束有没有交集”的逻辑判断；直接删 composer.lock 或硬加 --ignore-platform-reqs 不仅不解决问题，还会掩盖真实阻断点，让下次 CI 构建或新成员接入时更难复现。
用 composer why-not 定位真正封杀源
报错里写的 “don’t install monolog/monolog 3.0.0” 只是结论，composer why-not monolog/monolog:3.0.0 才告诉你谁在联合封杀。输出是反向依赖链，必须从最后一行（通常是你的根项目）倒着读：
- 最后一行显示
myapp/myproject dev-main → requires monolog/monolog ^2.8，说明你自己的composer.json卡死了范围 - 中间某行出现
laravel/framework v10.32.0 → requires symfony/console ^6.4，而另一行是package-x v2.1 → requires symfony/console ^5.4，那冲突点其实在symfony/console，不是monolog - 如果某行末尾带
conflict with guzzlehttp/guzzle (>=7.0)，别急着怪 Guzzle —— 这是它自己声明的硬性排斥规则，得查是谁把它拉进来的
定点更新比全量重算更安全
composer update 在大型项目中默认触发 SAT 求解器全量回溯，几百个包+多版本约束下极易卡死或内存溢出；盲目删锁文件等于放弃现场线索，重来一遍可能引入更隐蔽的组合问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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是关键：它只重算该包及其直系依赖，不会波及phpunit或sebastian/exporter这类测试工具链 - 升级后立刻
git diff composer.lock，确认改动仅限目标包和它的子依赖 —— 多改一个symfony/polyfill-*都可能在运行时暴雷 - 如果失败，说明子依赖链里还有硬冲突，此时再对新暴露出来的包跑一次
composer why-not
锁文件和平台配置必须对齐环境
本地 composer install 报 “Root requires X but Y is installed”，大概率不是代码问题，而是 composer.lock 和当前 PHP 版本、扩展或 platform 配置不一致导致的假冲突。
- 检查
composer.json顶层"config": {"platform": {"php": "8.1.0"}}是否匹配你实际运行的 PHP 版本；不匹配时 Composer 会模拟旧环境解析，结果和真实安装不一致 - 团队协作中拉新代码后出错，先
git checkout -- composer.lock恢复锁文件，再composer install—— 别假设别人提交了 lock 文件 - CI 环境务必加
COMPOSER_MEMORY_LIMIT=-1，并用composer update --dry-run预验证，避免构建中途因内存耗尽失败 -
composer install --prefer-dist --optimize-autoloader能跳过源码下载和冗余 autoload 生成，大幅缩短大项目首次部署时间
复杂点不在命令有多难记，而在每一步改动都会改变依赖图的求解空间——哪怕只是把 ^1.25 改成 ~1.25，就可能让 SAT 求解器从秒级回溯变成无法收敛。真正要盯住的，是 composer.lock 里每个包的真实版本、它被谁拉入、以及它的 conflict 字段是否意外生效。
