依赖冲突需先分类识别：PHP版本不匹配、platform配置锁死或require-dev混入运行时工具，不同类别解法迥异；硬套--ignore-platform-reqs会埋雷。
直接上结论：依赖冲突不是要“强行解决”，而是得先识别它是哪一类冲突——是 PHP 版本不匹配、平台配置锁死、还是 require-dev 里混进了运行时工具（比如 Rector）？不同类别的冲突，解法完全不同，硬套 composer update --ignore-platform-reqs 只会埋雷。
为什么 composer install 卡在 “Your requirements could not be resolved”
这不是网络慢，也不是权限问题，是 Composer 在做语义版本求解时发现根本不存在满足所有约束的包组合。常见触发点：
- 项目
composer.json里写了"php": "^8.2"，但你本地跑的是 PHP 8.1 —— Composer 会拒绝安装任何声明只兼容 8.2+ 的包 -
"monolog/monolog": "^1.0"和"symfony/console": "^6.0"同时存在，而 monolog v1.x 最高只支持 PHP 7.4，它和 Symfony 6 根本不在一个生态里 - 用了
composer create-project初始化项目，但没删掉模板自带的platform配置，导致整个依赖图被钉死在旧版本
验证方式：运行 composer diagnose，重点看 “PHP version” 和 “platform settings” 两行；再执行 composer why-not php:8.1（把 8.1 换成你实际环境的版本），它会列出哪个包在阻拦。
composer require 后 vendor/autoload.php 加载失败
这通常不是 autoload 配置写错了，而是文件权限或自动加载机制被破坏：
- Linux/macOS 下
vendor/目录被设成 777，PHP 运行用户（如 www-data）反而因安全策略拒绝读取 —— 改回755（目录）、644（.php 文件） - 你手动改过
autoload_psr4.php或autoload_classmap.php—— 别碰这些自动生成文件，一律用composer dump-autoload重建 - 项目用了
classmap+"optimize-autoloader": true，但新增类没在 classmap 路径下，又没重新 dump —— 此时 PSR-4 映射失效，类就找不到了
临时排查：在入口文件开头加 var_dump(get_included_files());，确认 vendor/autoload.php 是否真被引入；再查 vendor/composer/autoload_real.php 里注册的 loader 是否生效。
重构时怎么安全替换一个底层包（比如从 guzzlehttp/guzzle v6 升到 v7）
不能只改 composer.json 然后 composer update —— v6 和 v7 的 API 差异太大，Composer 不会帮你改代码。
- 先用
composer depends guzzlehttp/guzzle查哪些包依赖它，尤其是你自己写的类是否直接 new GuzzleHttp\Client() - 如果存在直调，先封装一层适配器（比如
HttpClientInterface），把 Guzzle 实例藏在背后，再逐步把业务代码迁移到接口 - 升级后立刻跑
composer outdated --direct，检查有没有其他包还没适配新 Guzzle —— 比如aws/aws-sdk-php某些老版本只认 Guzzle 6 - 别跳过
--with-dependencies：执行composer update guzzlehttp/guzzle --with-dependencies，让 Composer 主动拉取兼容的新版依赖链
最易被忽略的一点：很多项目把 Guzzle 当作“工具函数集合”用（比如直接调 GuzzleHttp\json_encode()），这种用法在 v7 里已被移除，必须提前 grep 扫描，否则上线就 fatal error。
