Composer依赖冲突90%源于约束未对齐或环境不一致，需先检查PHP版本匹配性、platform配置及详细日志定位阻断源，而非盲目删vendor或lock文件。
Composer 报依赖冲突，90% 不是包本身的问题，而是约束条件没对齐或环境不一致。 直接删 vendor 和 composer.lock 再跑 install，大概率白忙活——因为冲突根源在 php -v、composer.json 里的 "php" 约束、或 config.platform.php 配置上。
看报错末尾那句 requires php ^8.1 but your php version (7.4.33) does not satisfy that requirement
这是最典型的 PHP 版本不匹配提示。它不是说“你装的 PHP 不行”，而是说 Composer 当前正在用的 PHP 解释器版本（即 php -v 输出）和 composer.json 里 "require": {"php": "^8.1"} 不匹配。
- 别急着改
composer.json降版本——先确认你真需要兼容低版本 PHP；否则改了反而让代码跑不起来（比如用了match表达式） - 别盲目加
--ignore-platform-reqs——这等于关掉安全阀，vendor 里可能塞进一堆 8.1+ 语法，本地一运行就ParseError: syntax error, unexpected token "match" - 想用高版本 PHP 装低版本约束？必须显式调用目标二进制：
/usr/bin/php8.1 composer install（Linux/macOS）或"C:phpphp81php.exe" composer install（Windows） - CI 脚本里务必加
php -v打日志，否则根本不知道实际生效的是哪个 PHP
运行 composer update 卡住或报 conflict，但没明确提示哪个包冲突
默认输出太简略，根本看不出谁在拦路。得打开详细模式：
- 加
-v（verbose）：composer update -v，会列出每个包尝试解析时被拒绝的原因 - 加
--dry-run：先模拟不真装，看哪些包会被升级/降级/跳过 - 用
composer prohibits vendor/package查某个包为什么不能装，例如composer prohibits monolog/monolog会告诉你哪几个已装包要求了互斥的monolog版本 - 如果卡在某个包反复重试，可能是网络或仓库问题，可临时换镜像：
composer config repo.packagist composer https://packagist.phpcomposer.com（注意：该镜像已停更，建议用官方或阿里云镜像）
composer validate 提示 autoload 配置错误但类明明存在
常见于新增类后自动加载失效，或者迁移到新服务器时控制器 404。根本原因不是文件丢了，而是命名空间和路径没对齐。
- 检查
composer.json的"autoload"段是否包含对应映射，比如"psr-4": {"App\": "src/"}，那么src/Controller/UserController.php就必须声明namespace AppController; - 执行
composer dump-autoload -o（加-o生成优化映射），别只用dump-autoload，尤其在生产环境 - 确认文件权限和大小写：Linux 下
Src/和src/是两个目录，Windows 不敏感但 Composer 解析时会严格按路径字面匹配 - 如果用了
classmap，记得每次增删类文件后都要重新运行dump-autoload，它不会自动监听文件变化
删了 lock 文件重装还是冲突，怀疑 config.platform.php 在捣鬼
config.platform.php 是个“伪装成环境”的配置项——它不改变你当前 PHP 版本，只骗 Composer 在解析依赖时假装运行在那个版本上。
- 查当前生效值：
composer config platform.php（项目级）或composer config --global platform.php（全局） - 如果本地 PHP 是 8.1，但
platform.php设成了"8.2.0"，而你又没真在 8.2 环境下测试过所有包，那install成功后一跑就可能报错 - 清掉它：
composer config --unset platform.php，然后必须跟composer update --lock，否则composer.lock还记着旧平台信息 - 这个配置只适合打包部署场景（比如在 CI 里为 PHP 8.2 生产环境生成 vendor），日常开发请保持 unset
真正难缠的冲突往往藏在嵌套依赖的间接约束里，比如 A 包要求 symfony/console:^5.4，B 包要求 symfony/console:^6.0，而你没在 composer.json 里显式声明 symfony/console——Composer 就得自己选一个满足双方的版本，选不出来就死循环。这时候，prohibits 和 -v 就是你唯一能信的线索。
