Composer不支持多语言混编，依赖冲突仅限PHP生态内部；定位冲突须用composer why-not，升级应配合--with-dependencies并核对composer.lock变更。
Composer 本身不支持多语言混编——它只管 PHP 包，所谓“多语言混编依赖冲突”是误用概念。如果你在项目里同时用 PHP + Python/Node.js/Rust 等，各语言的依赖管理完全隔离，Composer 不会、也不能解析 requirements.txt 或 package.json 中的版本约束。冲突只发生在 PHP 生态内部。
composer why-not 是定位冲突的唯一可靠入口
报错里写的 “Conclusion: don’t install xxx” 只是结果，真正要查的是谁在联合封杀。运行 composer why-not vendor/package:version（比如 composer why-not symfony/console:^6.4），输出会逐行列出所有阻断该版本的包及其约束：
- 第一行通常是你的根项目（
myapp/myproject dev-main）在require字段锁死了旧版 - 后续行可能是
laravel/framework v10.30.0 requires symfony/console ^6.2这类间接依赖 - 如果某行显示
php: ^7.4，说明平台版本不匹配，不是语义化版本冲突
别跳过这步直接删 composer.lock——那等于扔掉现场证据，重装后冲突大概率复现，且更难回溯。
composer update --with-dependencies 定点升级才有效
盲目跑 composer update 会让 SAT 求解器全量重算，卡住 5 分钟以上很常见；只跑 composer update vendor/package 又默认不更新它的子依赖，容易失败。正确做法是：
- 先锁定冲突包，例如
monolog/monolog - 去 Packagist 查它的历史版本，找一个同时满足上下游约束的中间版（如
v2.9.3既在^2.0范围内，又 >=2.8.0） - 执行
composer update monolog/monolog --with-dependencies，让 Composer 同时考虑并更新其直接依赖
升级后立刻 git diff composer.lock，确认变更仅限预期范围——多改一个 symfony/polyfill-* 都可能引发运行时错误。
platform 配置不是万能补丁，而是环境对齐开关
很多人以为加 "config": { "platform": { "php": "8.1.0" } } 就能“解决”冲突，其实它只做一件事：告诉 Composer 忽略你本地的 PHP 版本，按指定环境解析依赖。它对 ^1.0 vs ^2.0 这类语义化版本冲突完全无效。
- 真实作用：避免因本地 PHP 7.4 而无法安装要求 PHP 8.1 的包（此时
--ignore-platform-reqs才是临时绕过手段） - 危险操作：把
platform设成"php": "8.3.0"却在 PHP 8.1 环境下部署，运行时可能因缺少新语法或扩展直接崩溃 - 检查当前生效平台配置：运行
composer show --platform
真正容易被忽略的是 conflict 字段的全局性——哪怕你没 require 某个包，只要其他已装包间接拉入，conflict 规则就会触发。它不是提示，是硬拦截。
