ThinkPHP 项目中必须通过 composer 精准管控依赖版本，盲目 update 会导致 framework 与 ORM 等官方包版本错位而报错；升级需显式约束版本、清空 vendor 和 lock 文件后 install，降级须还原 lock 或强制 require 旧版，并始终 dump-autoload 和清缓存。
ThinkPHP 项目里，composer 不是“插件”，而是你真正掌控依赖的唯一入口；盲目 composer update 很可能让 topthink/framework 升到 v8，但 topthink/think-orm 还卡在 v2.x，直接报 Class not found: think\Model —— 这不是框架问题，是你没管住依赖对齐。
为什么不能直接 composer update
TP 官方包之间有强版本绑定关系：topthink/framework v8.0 要求 topthink/think-orm ≥ v3.0，而 v7.x 只认 v2.x。裸跑 composer update 会让 Composer 各自求解约束，结果框架和 ORM 版本错位。
- 常见错误现象：
Call to undefined method think\Model::with()（ORM 太旧）、Target class [think\view\driver\Think] does not exist（think-view没同步） - 运行
composer outdated topthink/*是必须前置动作：带!的行表示主版本跃迁（如7.4.0 → 8.0.0），需查迁移文档 - 若
topthink/think-orm显示 “up to date” 但framework已是 v8，说明它尚未适配——别硬推，等官方发新版
安全升级全家桶的三步实操
以 TP v7 → v8 升级为例，核心是“改约束 → 清环境 → 重装”，不靠自动求解。
- 编辑
composer.json，把所有topthink/包的版本约束显式写死："topthink/framework": "^8.0"、"topthink/think-orm": "^3.0"、"topthink/think-view": "^2.0"（注意不是*或dev-main） - 删掉
vendor/和composer.lock（TP 主版本升级常伴随平台扩展要求变化，重装更干净） - 执行
composer install --no-dev（加--no-dev避免测试工具链冲突；确认无误后再补require-dev） - 升级后立刻跑
composer dump-autoload -o，否则php think命令和自动加载会失效
更新指定包时的精准控制
生产环境要升 topthink/framework 到 v6.3.10？别用全局 update，用受控方式锁定影响范围。
立即学习“PHP免费学习笔记（深入）”；
- 改
composer.json中"topthink/framework": "^6.3.10" - 执行
composer update topthink/framework（只更新该包及其直系依赖，不碰其他） - 若失败且提示
putenv() has been disabled，去服务器面板启用该函数并重启 PHP 服务 - 更新后务必运行
composer dump-autoload，否则新类路径不会进自动加载映射
回滚比升级更常发生
升级后路由异常、中间件报错，第一反应不该是查代码，而是检查依赖是否复位。
- 如果用了 Git 且
composer.lock已提交：用git checkout HEAD~1 -- composer.lock还原，再rm -rf vendor/ && composer install --no-dev - 如果没 Git 历史但知道旧版号：用
composer require topthink/framework:v6.0.15 --with-all-dependencies强制降级 - 无论哪种方式，回滚后都得清缓存：
php think clear，否则旧路由规则、中间件配置仍可能生效
最易被忽略的点：TP 主版本升级后，composer.lock 必须重新生成并提交，且所有环境（包括 CI）必须用 composer install 而非 update；否则本地能跑，线上因依赖树差异直接崩。
