composer依赖冲突本质是多个包对同一依赖的版本范围无交集，如^2.0与~1.25互斥；需用composer why-not倒序定位根因，查packagist找共适版本，优先调整可控包约束而非删锁文件。
Composer 依赖声明版本冲突不是语法错误，而是多个包对同一依赖提出的版本范围没有交集——它根本不会装，不是装错了。
composer.json 里 ^ 和 ~ 的差异直接决定能否找到交集
写错一个符号，就可能让 Composer 彻底找不到解。比如 ^1.2.3 表示 >=1.2.3 ，而 <code>~1.2.3 只表示 >=1.2.3 。如果 A 包要求 <code>"monolog/monolog": "^2.0"，B 包要求 "monolog/monolog": "~1.25"，它们的版本区间完全不重叠，Composer 就会直接放弃。
- 去 Packagist 查目标包的实际发布记录，确认哪些版本号同时被多个依赖接受（例如
2.9.3可能被^2.0和>=2.8.0同时覆盖） - 别盲目改
^为~或反之——先看该包是否真按语义化版本发布；很多国产包标着v2.0.0却在2.1.0里破坏 API，这时^2.0就是陷阱 - 若必须兼容两个主版本，可写
"monolog/monolog": "^1.25 || ^2.10"，但前提是你的代码能同时调通两套 API，否则只是把问题推迟到运行时报错
require-dev 是最常被忽略的冲突源头
报错里没提测试工具，不代表它没参与解析。比如 phpunit/phpunit 可能悄悄拉入一个锁死 symfony/console 在 5.x 的旧版本，而你主项目要 Laravel 10（要求 symfony/console ^6.4），冲突就卡在这儿。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 执行
composer why-not symfony/console:^6.4，输出最后一行才是你的根依赖，往上倒着读才能定位真实阻断点 - 用
composer show --tree | grep -A5 -B5 console快速筛出谁在拉哪个版本的 console - 别在
require-dev里塞和主框架不匹配的包，比如主项目用laravel/framework: ^10.0，就别引入orchestra/testbench: ^7.0（它硬绑 Laravel 9）
改 composer.json 不是调数字，而是找约束交集
看到冲突就删 vendor/ 和 composer.lock，等于把诊断证据一起扔了。真正要动的是约束本身。
- 优先改你控制的包：如果是私有 SDK（如
acme/payment-sdk），去它的composer.json放宽对底层库的约束，比硬改主项目更安全 - 用具体版本号代替模糊约束：
"monolog/monolog": "2.9.3"，再执行composer update monolog/monolog单点更新，避免牵连其他依赖 - 检查
conflict字段是否误伤——比如写了"conflict": {"laravel/framework": ">=11.0"}，但项目根本没用 L11，只要某个已装包间接拉进 L11 的某子依赖，就会触发拒绝
composer why-not 输出要倒着看，最后一行才是 root
它输出的不是“谁拦你”，是一条拒绝理由链。每行末尾的 (required by ...) 是向上追溯的起点，得从最后一行开始倒推。
- 最后一行通常是类似
myapp/myproject dev-main requires guzzlehttp/guzzle (^6.5)—— 这才是你主动写的约束 - 往上一行可能是
laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)—— 这说明冲突不在 sanctum，而在 guzzle 的版本无交集 - 接着跑
composer why guzzlehttp/guzzle，确认是不是某个 require-dev 里的包（如phpunit/phpunit）把它锁死了
真正难的不是命令怎么敲，而是读懂 composer why-not 输出里哪一行是“根因”、哪一行是“传导路径”。一旦看反顺序，就会去修一个根本没参与约束的包。
