先运行 composer show -t 查依赖树定位 A→B→C→A 类闭环，再用 composer depends --tree 和 composer prohibits 分析反向依赖与版本冲突，最后检查 platform 配置、扩展缺失及 autoload 设置。
composer install 报错 “Your requirements could not be resolved” 怎么快速定位循环依赖
Composer 本身不直接报“循环依赖”这个词，它只说依赖无法满足——真正的问题往往藏在 composer show -t 的树形输出里。先跑这行命令，再肉眼找有没有 A → B → C → A 这类闭环路径。
常见错误现象：composer update 卡住不动、或反复尝试不同版本后失败；composer why 查某个包被谁引入时，发现它既被 root 引入，又被自己间接引入（比如 your-project → pkg-a → pkg-b → pkg-a）。
- 别急着删
composer.lock或清缓存——这只会让问题更难复现 - 用
composer depends --tree <package-name>看反向依赖链，比show -t更聚焦 - 如果某包同时出现在 require 和 require-dev 里（且版本不一致），也会触发冲突，这时要统一移到 require 或 require-dev 中
两个包声明了互斥的 PHP 版本或扩展依赖怎么办
比如 pkg-a 要求 php: ^8.1，而 pkg-b 锁死在 ext-gmp: * (missing)，但你的环境没装 gmp 扩展——Composer 不会告诉你缺扩展，只会报“no matching package found”。
使用场景：CI 环境构建失败、本地换 PHP 小版本后突然不能装包。
- 运行
composer check-platform-reqs，它会明确列出缺失的 PHP 版本和扩展 - 检查
composer.json里的config.platform是否伪造了不存在的环境（比如设了"php": "8.2"但实际是 8.1） - 扩展冲突常发生在
ext-xml/ext-json这类基础扩展上，它们默认开启但可能被禁用；用php -m确认真实加载列表
require 和 require-dev 里用了同一包的不同版本，为什么 composer update 会失败
Composer 把整个项目当做一个整体解析依赖，require 和 require-dev 是合并处理的。哪怕你在 dev 里写 "monolog/monolog": "^2.0"，在 require 里写 "monolog/monolog": "^3.0"，它也会拒绝安装——因为最终只能选一个版本共存。
性能影响：这种冲突会让 Composer 回溯大量版本组合，耗时剧增，甚至 OOM。
- 用
composer prohibits monolog/monolog查哪个地方锁死了低版本 - 开发阶段可临时加
--with-all-dependencies强制升级，但上线前必须清理掉 require-dev 对生产包的版本干扰 - 更安全的做法是：把仅 dev 需要的包（如
phpunit/phpunit）严格限定在 require-dev，并确认它没通过其他路径意外拉进 require 树
vendor/autoload.php 加载失败，但 composer install 显示成功
这不是依赖冲突，而是 autoloader 生成逻辑被破坏了——典型原因是手动改过 composer.json 的 autoload 段，又没跑 composer dump-autoload。
容易踩的坑：在 CI 脚本里只跑 composer install --no-dev，却忘了某些 autoloading 规则（比如 PSR-4 映射）是在 require-dev 包里定义的；或者用了 classmap 但文件被 gitignore 掉了。
- 检查
vendor/composer/autoload_*.php文件是否存在且非空 - 运行
composer dump-autoload -o强制重生成优化版自动加载器 - 如果用了自定义 autoload 类型（如
files），确认对应 PHP 文件路径拼写正确、权限可读、没被 .gitignore 屏蔽
依赖解析真正的难点不在规则多，而在所有约束条件（PHP 版本、扩展、平台配置、稳定性标志、版本运算符优先级）是同时生效的。少看报错第一行，多翻 composer show -t 和 composer prohibits 的输出。
