composer.lock 是可信版本快照，冲突源于 composer.json、已安装包与 PHP 版本间的逻辑矛盾；用 composer update --dry-run -v 快速定位根源，重点关注 Root requirements 和反复出现的包名。
composer.lock 文件不是“过期就要删”，而是你当前环境唯一可信的版本快照；冲突不是它导致的，而是它忠实地暴露了 composer.json、已安装包、PHP 版本之间的真实矛盾。
composer install 报 “Conclusion: don’t install xxx” 怎么快速定位冲突源
这是 Composer 依赖解析失败最典型的提示，本质是 composer.lock 里记录的版本与当前 composer.json 约束或已安装包不兼容。不是配置写错了，而是约束之间存在逻辑矛盾。
- 先运行
composer update --dry-run -v：它不改任何文件，但会完整走一遍依赖求解，末尾几行直接写出冲突根源，例如Because package-a v2.1 requires symfony/console ^5.4, and package-b v3.0 requires symfony/console ^6.0 - 重点盯住报错末尾的
Root requirements段落——它指出是你composer.json里哪一行（比如"topthink/framework": "^6.2"）触发了整条链的崩塌 - 别忽略反复出现的包名，如
monolog/monolog、psr/log、phpunit/phpunit，它们大概率是冲突枢纽 - 检查 PHP 版本约束是否被忽略：
"php": "^8.1"写在composer.json顶层，但某个依赖只支持 7.4，Composer 就会卡死在这里
为什么 composer update 不升级某些包，即使新版本明明满足约束
Composer 默认采用“最小变更”策略：只要现有已安装版本符合 composer.json 的约束（比如 "guzzlehttp/guzzle": "^7.2"），就不会主动升级到 7.8 或 7.9，哪怕它们更稳定、有安全修复。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 想强制升级单个包：用
composer update guzzlehttp/guzzle，不加--dry-run时它会重算该包及其直接依赖 - 想避免跨大版本跳跃：用带引号的约束，例如
composer update "guzzlehttp/guzzle:^7.0"（引号防 shell 解析错误） - 想只升次要版本（7.2 → 7.8，但不升到 8.x）：确保约束写的是
^7.0而非*或>=7.0，再配合--with-dependencies -
composer outdated能列出所有可更新包及当前/最新版本，比盲猜靠谱得多
composer why-not 和 composer prohibits 怎么精准查拦路虎
这两个命令比翻 composer.lock 快十倍，结果精准到具体版本号和依赖路径，专治“谁在挡路”和“谁被它挡了”。
-
composer why-not psr/log:3.0.0→ 查谁在阻止psr/log升到 3.0.0（注意必须写全包名+版本号） -
composer prohibits monolog/monolog:^2.0→ 反向查：当前项目里哪些包强制要求monolog/monolog的旧版（比如^1.25），从而把 2.x 挡在外面 -
composer depends --tree topthink/framework→ 查哪些已安装包显式或间接依赖它，常用于 TP5/TP6 混用排查 - 如果报
[InvalidArgumentException] Package not found，说明该包还没在composer.json或lock里声明过，别白费劲
require-dev 是不是真需要放 require 里
绝大多数情况下不需要。require-dev 里的包（如 phpunit/phpunit、phpstan/phpstan）参与统一依赖解析，但它们本不该影响线上行为——却常常悄悄拉低主依赖的版本上限。
- 执行
composer update --no-dev可临时绕过require-dev验证，快速确认是不是 dev 依赖拖了后腿 - 仅本地开发、CI 或调试用的包（比如
barryvdh/laravel-debugbar）→ 必须放require-dev，而不是require - 如果某个包在 dev 和 prod 都需要，但版本要求不同（比如 prod 用 v1，dev 用 v2），那就不能共存，得用
conflict显式声明互斥 - 上线部署时务必用
composer install --no-dev，彻底跳过这些包；否则 autoload-dev 中的类可能污染生产 autoload.php
真正危险的操作不是锁文件“旧”，而是没看清 composer.json 里那一行看似宽松的 "*" 或 "^2.0" ——它可能正和另一个包的 "!=3.0.0" 在后台激烈对峙，而你只看到报错里一闪而过的 Conclusion: don't install。
