Composer后端服务依赖冲突_Composer API接口版本冲突排查【实战】-composer-PHP中文网

composer依赖冲突根源在require-dev、conflict字段或psr-4命名空间错位；定位需倒读composer why-not输出，紧盯带conflict或版本互斥的行；api升级后类/方法找不到主因是命名空间或autoload映射错误。

composer后端服务依赖冲突_composer api接口版本冲突排查【实战】

Composer 依赖冲突不是包装不上，而是多个 API 接口契约在底层互相拉扯——根源常藏在 require-dev、conflict 字段或 PSR-4 命名空间错位里，不是删 vendor 就能解决的。

composer why-not 看到一堆嵌套，怎么快速定位真正卡住的包

输出是反向依赖链，必须从最后一行倒着读：最后一行是你的 composer.json 根要求（比如 "myorg/api": "^2.3"），往上每行末尾的 (required by ...) 才是真实阻断点。重点盯住带 conflict 或版本范围明显互斥的那行，例如：

spatie/laravel-backup 7.0.0 requires illuminate/support (^9.0)
└── your-project requires laravel/framework (^10.0)

这里真正拦路的是 spatie/laravel-backup 对 illuminate/support 的约束，不是 laravel/framework 本身。它没声明支持 ^10.0，而你又没升级它，Composer 就只能放弃。

如果某行出现 php 或扩展名（如 ext-json），立刻检查 php -v 和 composer show --platform
输出为空？说明目标包根本没被任何已安装依赖引用，可能是你刚加进 composer.json 但还没 composer update
看到 your-project-name 出现在中间路径？说明你自己写的 require 或 conflict 字段有逻辑矛盾

API 包升级后接口调用报 Class not found 或 Method not found

这不是 Composer 装错了，是命名空间或自动加载映射没对齐。尤其常见于从 TP5 升 TP6、Laravel 9 升 10、或私有 SDK 拆包后。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

查 composer.json 的 autoload 段：如果包声明 "psr-4": {"MyOrg\Api\": "src/"}，那 src/Client.php 必须写 namespace MyOrgApi;，少一个反斜杠或大小写错都会失效
TP6 项目里还用 new hinkRequest()？这会直接 Class 'thinkRequest' not found，必须改成 hinkacadeRequest::instance()
升级 SDK 后方法消失？先 composer show myorg/api 确认装的是目标版本，再进 vendor/myorg/api/src/ 看对应类文件是否存在、方法是否被移到 trait 或 facade 里
别信“自动迁移脚本”——很多把 AppHttpControllers 改成 AppControllers，却漏掉 config/app.php 里的 'namespace' => 'App' 配置，导致控制器 404

为什么 composer update vendor/package 不生效，还是旧版本

Composer 默认走“最小变更”策略：只要当前已装版本满足 composer.json 里的约束（比如 "guzzlehttp/guzzle": "^7.2"），就不会动。改完 JSON 文件不等于自动刷新。

执行 composer update vendor/package（不是 install），才触发重解析
想连带更新它的子依赖（比如 guzzlehttp/psr7、psr/http-client），必须加 --with-dependencies
如果只想要小版本升级（7.2 → 7.9，不跳 8.x），确保约束写的是 "^7.2"，而不是 "*" 或 ">=7.0"
运行 composer show vendor/package 看 “versions” 列表，确认你要的版本确实在 Packagist 上发布过；有些包只推了 dev-main 分支，稳定版还没打 tag

require-dev 是最隐蔽的 API 冲突来源

很多“线上能跑、本地测试挂”的问题，根源是 require-dev 里塞了和主流程冲突的工具链。例如：

phpunit/phpunit v9.x 拉入 symfony/console v5.x，而你的 API 包依赖 symfony/console v6.x，一跑测试就爆冲突
friendsofphp/php-cs-fixer 锁死 phpstan/phpstan v1.10，但主业务包需要 v2.0+ 的类型推导能力
CI 脚本里没清缓存，COMPOSER_HOME 共享导致不同项目的 autoload_psr4.php 相互污染

临时验证：删掉 require-dev 整个区块，跑 composer install --no-dev，如果不再报错，基本锁定是 dev 工具反向污染了主依赖链。