composer install -v是上线前必跑的检测命令，可暴露依赖冲突根源、定位枢纽包、验证修复路径；配合composer why-not和composer show --tree能精准识别约束链与版本冲突点。
上线前发现 Composer 依赖冲突，不是重装 vendor 就能解决的；真正要做的，是让冲突在部署前就暴露出来、定位到具体包、验证修复路径是否安全。
composer install -v 是上线前必跑的检测命令
CI/CD 流水线里只跑 composer install 是危险的——它遇到冲突直接失败，但不告诉你为什么。加 -v 才能看到真实约束链和首个冲突点。
- 输出里反复出现的包名（如
symfony/console、monolog/monolog）大概率是枢纽冲突源，优先盯住 - 重点看形如
Root composer.json requires package-a ^1.2, but package-a 1.2.0 conflicts with another require的行，这是冲突起点 - 末尾的
Conclusion: don't install X不是原因，是求解器放弃前的最后尝试；真正原因藏在它上面几百行里 - 如果输出中出现
your-project-name，说明是你自己的composer.json里写了互斥约束（比如同时 require 了两个不兼容的 Laravel 扩展）
composer why-not vendor/package:version 定位“谁在拦路”
你想升 guzzlehttp/guzzle 到 ^8.0 却失败？别猜，直接问 Composer：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer why-not guzzlehttp/guzzle:^8.0，它会列出所有阻止该版本的已声明依赖，包括间接依赖 - 输出为空？说明这个版本根本没被任何现有依赖声明过——可能是 Packagist 镜像未同步，或该版本不在 stable channel
- 注意：它不检查 PHP 版本是否匹配，这类问题得靠
composer check-platform-reqs单独验证 - 如果输出里有
your-project-name，说明是你自己在composer.json的require或require-dev里锁死了旧版
composer show --tree + grep 快速穿透多层依赖
很多冲突不来自你写的 require，而是某依赖的依赖悄悄引入了不兼容版本。树状展开才能看清真实路径：
- 运行
composer show --tree monolog/monolog | grep "symfony/.*console"，快速过滤出关键枢纽包的嵌套关系 - 每行末尾带
(locked to 3.5.0)表示该版本已被composer.lock固定；删 lock 文件再composer update才可能松动 - 如果某个包在树里出现多次且版本不同（如
symfony/console同时被laravel/framework和phpunit/phpunit引入），这就是典型冲突温床 - 别忽略
require-dev——phpunit/phpunit对symfony/console的要求，常和生产环境的laravel/framework冲突
上线前必须核对三处 PHP 版本一致性
90% 的 “requires php ^8.1 but your php version is 7.4.33” 类错误，根源不在包本身，而在环境错配：
- 执行
php -v确认 CLI 实际版本（Composer 走的是 CLI，不是 Web SAPI） - 运行
composer config platform.php查看是否手动设了平台版本；若设了，必须和php -v输出一致 - 检查
composer.json中"require": {"php": "^8.1"}是否真需要——降级这里可能引入语法错误（比如match表达式） - CI 脚本里务必加
php -v日志，否则根本不知道实际生效的是哪个 PHP 二进制
最易被忽略的点：composer.lock 文件可能包含你手动 fix 过的历史妥协，直接删除再 install 会导致其他环境行为突变；真正的上线前检测，是让冲突在 install -v 和 why-not 阶段就浮出水面，而不是等部署失败后翻日志。
