应先用 composer why-not 和 prohibits 命令定位冲突源，再删 composer.lock 重装或单独更新冲突包；锁版本需避免 ^/~ 符号，用 --no-update 确保精确。
composer install 报错 “can’t resolve dependencies” 怎么办
这不是网络问题，是 composer.json 里声明的包版本范围和已有的 composer.lock、或远程仓库可用版本对不上。Composer 没法找到一组同时满足所有约束的版本组合。
- 先运行
composer why-not vendor/package:version查具体哪个包在阻挠——它会告诉你谁依赖了冲突包的旧版 - 删掉
composer.lock再跑composer install是最粗暴也最有效的重算方式（前提是项目没锁定生产环境版本） - 如果用了
"prefer-stable": true，但某个包只发布了dev-分支，也会卡住；临时改成false看是否能过
require 命令加了新包，却提示 “your requirements could not be resolved”
新包的 composer.json 里声明的依赖（比如要求 php: ^8.1 或 symfony/console: ^6.4），和你当前项目已有的其他包不兼容。
- 别急着降级 PHP 或改框架版本，先用
composer prohibits vendor/package:version反查：哪些现有包禁止这个版本被装上 - 检查新包的
require字段（去 Packagist 页面看），确认它是否真需要你项目里没有的扩展（如ext-intl） - 如果只是小版本冲突（比如要
monolog/monolog:^2.10，而你锁的是^2.9），可尝试composer update monolog/monolog --with-dependencies单独升它
composer update 后部分功能异常，但没报错
这通常不是 Composer 的锅，而是上游包做了 BC break（哪怕只是改了方法签名、返回类型或默认行为），而你的代码没适配。
- 对比
composer.lock更新前后的哈希值，重点关注出问题模块及其直接依赖项的版本变动 - 运行
git diff composer.lock，快速定位哪些包升级了；再查对应包的 CHANGELOG（尤其是 MAJOR 版本跳变） - 如果用了
composer update --dry-run，它不会告诉你 break，只会告诉你“能装”，所以不能替代实际测试
想锁死某包版本，但 require 时写死了却还是被更新了
因为 composer update 默认更新所有包，除非显式指定。写 "vendor/package": "1.2.3" 只是约束下限，不是钉死。
- 真正锁死要用
composer require vendor/package:1.2.3 --no-update，然后手动编辑composer.json中该行，确保没波浪线~或插入号^ - 更稳妥的做法是删掉该包条目，执行
composer require vendor/package:1.2.3 --no-update，再composer install - 注意：某些包（如
phpunit/phpunit）在require-dev里，但被require里的其他包间接依赖，也会被带进来——得一起查
why-not 和 prohibits 这两个命令，比翻 composer.json 有效得多。 
