生产环境绝不能运行composer update，因其会重算依赖树、跳过composer.lock锁定，可能升级到不兼容主版本（如guzzlehttp/guzzle 7.x→8.x），导致运行时500错误；必须通过composer why-not定位冲突、composer update package --with-dependencies精准收敛，确保变更可预测、可回滚。
生产环境不能靠 composer update 硬扛冲突，必须让变更可预测、可回滚、不破坏运行时行为。
为什么生产环境绝不能直接 run composer update
因为 composer update 会重算整个依赖树，可能升级到不兼容的主版本（比如把 guzzlehttp/guzzle 从 7.x 升到 8.x），而你的代码里还写着 new GuzzleHttp\Client() —— 这类 break change 不会在 CI 里被静态检查捕获，上线后直接 500。
- 它跳过
composer.lock的锁定保障，等同于放弃环境一致性 - 即使加了
--no-dev，也不能阻止 require 中包的跨主版本升级 - 团队协作中，你本地
update后没提交composer.lock，别人install就会失败
线上修复冲突的三步安全流
遇到报错如 found 2 packages with version constraints that differ，别删 lock 文件重装，按顺序做：
- 先定位：运行
composer why-not vendor/package:desired-version，看哪个包在卡住升级路径 - 再验证：用
composer show -t | grep package-name检查当前实际安装的版本和它的父依赖链 - 最后收敛：只更新冲突点本身，例如
composer update monolog/monolog --with-dependencies，而不是全量 update
这个操作会强制重算 monolog/monolog 及其子依赖，但不会动其他分支，影响面可控。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
require-dev 包引发的 Class not found 怎么防
典型现象：加了 --no-dev 部署，但运行时报 Class 'Symfony\Component\VarDumper\VarDumper' not found —— 因为 symfony/var-dumper 被写进了 require-dev，但你在控制器里写了 dump($data)。
-
require-dev不等于“运行时不加载”，只要业务代码里有use或new，它就是运行时依赖 - 上线前必须执行
grep -r "var-dumper\|dump(" src/ app/，确认没有隐式引用 - CI 流程里加一步
composer dump-autoload --no-dev && php -l，提前暴露 autoload 缺失问题
锁文件损坏或 URL 失效怎么办
常见报错：package x is not installed，但 vendor/ 里确实没这个目录。这不是冲突，是 composer.lock 记录的 dist ZIP 地址已失效（比如 GitHub release 被删、Packagist 同步延迟）。
- 不要手动删
vendor/和composer.lock，那等于放弃一致性 - 先运行
composer install --ignore-platform-reqs --no-dev，跳过平台检查强行拉取 - 若仍失败，用
composer show vendor/package查真实可用版本，再手动编辑composer.lock替换对应包的dist.url和dist.shasum字段（需同步更新packages-dist数组）
最易被忽略的是：锁文件里某个包的 source 类型（如 git）和 dist 类型共存时，Composer 默认优先走 dist；一旦 dist 失效，它不会自动 fallback 到 source，而是直接报错。
