ThinkPHP版本冲突本质是Composer依赖图中多个包对topthink/framework等核心包提出互斥版本要求，需用composer why-not和prohibits连查源头，锁死小版本、隔离TP5/TP6混用、修正autoload路径并避免COMPOSER_HOME共享污染。
ThinkPHP 版本冲突不是“装不上”，而是 Composer 在解析依赖图时发现多个包对同一个核心包（比如 topthink/framework）提出了互斥的版本要求。直接删 vendor 或硬改 composer.json 的 require 字段，大概率会让问题更难回溯。
composer why-not 和 prohibits 必须连着用
报错里出现 “don’t install thinkphp/framework v6.0.10” 或 “can’t be installed because it conflicts with another package”，说明某个包在拦路。单靠 composer why 只能看到谁“用了它”，看不到谁“不让它装”。
- 先跑
composer why-not topthink/framework:6.0.10（把版本换成报错里那个）——它会告诉你哪个包明确拒绝这个版本 - 再跑
composer prohibits topthink/framework:6.0.10——它会列出所有正在“拉扯”这个版本的包，包括间接依赖 - 重点看输出里带
topthink/think-*或第三方扩展名（如topthink/think-swoole、overtrue/laravel-wechat）的行，它们大概率是冲突源
TP5 和 TP6 混用是隐形炸弹
Composer 不校验命名空间，只认 require 字段。所以你可能在 TP6 项目里装了一个标着 "require": {"topthink/framework": "^5.1"} 的旧扩展，它不会立刻报错，但运行时一调用 \think\Request 就炸：Class 'think\Request' not found。
- TP5 的类在
think\*根命名空间下；TP6 全部移到think\facade\*和think\contract\* - 检查所有扩展包的 GitHub issues，搜 “
TP6”、“6.2”、“version conflict”，别信 README 里写的 “支持 TP6” - 如果某个扩展没适配 TP6.2+ 的容器注入机制，就别升级框架主版本，或换掉它
锁死小版本比写 ^ 更可靠
ThinkPHP 生态对版本敏感度远高于 Laravel。^6.1.0 会允许升到 6.3.0，但很多扩展只测过 6.1.x，6.3 一上来就重构了请求类路径或中间件生命周期。
立即学习“PHP免费学习笔记（深入）”；
- 在
composer.json里显式写死小版本："topthink/framework": "6.1.5"，不是"^6.1.0" - 配套的 ORM、View 等也同步锁死：
"topthink/think-orm": "3.0.14"，避免它们自己悄悄拉高框架依赖 - 升级前先确认所有插件已适配目标版本，尤其注意
think-swoole、think-queue这类高频扩展
autoload.php 加载失败往往不是自动加载器的问题
TP5.1 升 TP6 后报 Class 'think\Route' not found，或者 CI/CD 构建后 CLI 脚本报 vendor/autoload.php 找不到，本质是 PSR-4 映射规则变了，或脚本里用了错误的相对路径。
- 入口文件或测试脚本里别再写
new \think\Request()，必须改成\think\facade\Request::instance()或app('request') - 手动
require自动加载器时，避免用__DIR__.'/../vendor/autoload.php'这类易受目录层级变动影响的写法 - 统一用
dirname(__DIR__).'/vendor/autoload.php'或更稳妥的require_once __DIR__.'/../../../vendor/autoload.php'
最常被忽略的一点：同一台服务器部署多个 ThinkPHP 项目时，COMPOSER_HOME 共享会导致 autoload_psr4.php 互相污染。哪怕只是本地开发环境，也建议每个项目单独配置 COMPOSER_HOME 或用 composer install --no-dev 隔离。
