Composer依赖冲突需先用composer why-not和depends查源头，锁死topthink/framework等关键包小版本，隔离require-dev依赖，严审第三方扩展的版本范围。
Composer install 报错 “can’t be installed because it conflicts with another package”
这是最典型的依赖冲突表现，ThinkPHP 项目里常因 topthink/framework 版本和第三方扩展（比如 overtrue/laravel-wechat、league/flysystem）要求的 psr/log 或 symfony/finder 版本不兼容触发。
别急着删 vendor 或降级 ThinkPHP——先看冲突源头：
- 运行
composer why-not vendor/package:version（如composer why-not psr/log:3.0.0），查谁在拦路 - 用
composer depends --tree vendor/package看依赖树，定位是哪个扩展间接拉高了版本要求 - ThinkPHP 6.1+ 默认要求
psr/log ^2.0，但某些新包只支持^3.0，这时不能硬升，得干预
锁定核心包版本：避免 Composer 自动升级破坏兼容性
ThinkPHP 不是 Laravel，它的生态对版本敏感度更高。盲目允许 ^ 或 ~ 会引发运行时报错，比如 Class Request does not exist（因 topthink/framework 升到 6.3 后重构了请求类路径）。
稳妥做法是在 composer.json 中显式锁死关键包：
立即学习“PHP免费学习笔记（深入）”；
"require": {
"php": ">=7.3.0",
"topthink/framework": "6.1.5", // 不写 ^6.1.0，写死小版本
"topthink/think-orm": "3.0.14",
"topthink/think-view": "3.0.1"
}
注意：6.1.5 是稳定快照，比 6.1.* 更可控；若用 6.2+，务必确认所有插件已适配（很多老扩展至今没兼容 6.2 的容器注入机制）。
排除冲突包：require-dev 里的测试工具偷偷拖垮生产环境
常见陷阱：本地开发装了 phpunit/phpunit 或 mockery/mockery，它们依赖新版 sebastian/exporter，而该包又要求 php >=8.1，直接卡住 PHP 7.4 的 ThinkPHP 项目。
解决不是删掉测试工具，而是隔离它：
- 把开发依赖移到
require-dev，并加"minimum-stability": "stable"防止 dev 包污染主依赖 - 上线部署时用
composer install --no-dev，彻底跳过这些包 - 如果 CI/CD 流程里仍报错，检查是否误将
autoload-dev中的类注册进了生产autoload.php
ThinkPHP 扩展包的 require 写法必须手审
很多第三方 ThinkPHP 扩展在 composer.json 里写 "require": {"topthink/framework": "^6.0"}，看着没问题，实则埋雷——这个范围会匹配 6.3，但扩展本身可能只测过 6.0–6.1。
遇到这种包，别信它的 require，要自己验证：
- 查该扩展 GitHub 的
issues，搜 “6.2”、“6.3”、“version conflict” - 看它的
src/下有没有Facade类，6.2+ 废弃了部分 Facade 注册方式，旧写法会直接Class not found - 临时改其
vendor/xxx/xxx/composer.json，把topthink/framework改成具体小版本再composer update xxx/xxx测试
真正麻烦的不是装不上，是装上了跑一半才报错——比如日志驱动初始化失败、中间件顺序错乱。这类问题往往要翻 think\facade\Log 和 think\Pipeline 的源码才能定位，比解决冲突本身更耗时间。
