安装thinkphp时默认会装最新稳定版（如v8.x），需显式指定版本如"6.1.0"或"^6.1"；已装错则删vendor/topthink及composer.lock中相关行后重装；composer.lock必须提交git以保证版本一致。
composer require 安装 ThinkPHP 时为什么总是装错版本
默认执行 composer require topthink/think 会拉取最新稳定版（比如 v8.x），但很多项目依赖 v6.1 或 v7.0，不显式指定就会踩坑。Composer 不会自动识别你心里想用的版本，它只认 require 后面写的约束。
- 不写版本号 → 安装最新
stable版，可能含破坏性变更 - 写
^6.1→ 允许升级到6.x任意小版本，但不会升到7.0 - 写
6.1.0（无符号）→ 精确锁定，后续composer update不会动它 - 若已装错，先删
vendor/topthink和composer.lock中相关行，再重装
如何在现有项目中降级或锁定 ThinkPHP 6.1
不是所有项目都能直接升 v8，尤其用了大量 think\facade\Db 或自定义命令的旧代码。这时候得主动干预 Composer 的解析逻辑，靠 composer.json 的 require 字段硬控。
- 编辑
composer.json，把"topthink/think": "^6.1"改成"topthink/think": "6.1.0" - 运行
composer update topthink/think（别用update全量，避免连带升级其他包） - 检查
composer.lock中topthink/think对应的version是否为6.1.0 - 注意：v6.1 要求 PHP >= 7.2，低于该版本会报
Your requirements could not be resolved
ThinkPHP 7 和 8 的核心兼容差异在哪
v7 是 v6 的平滑演进，v8 则重构了应用生命周期和容器机制，很多老写法会直接报错，比如 think\App::run() 在 v8 中已移除，think\facade\Cache 默认不再自动初始化。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- v7 仍支持
app()->make()和传统门面调用，v8 强制要求用app()+get()或依赖注入 - v8 的
config/目录结构变化，database.php拆成db.php和cache.php，硬拷配置会连不上数据库 - 如果你用
think-queue或think-swoole，确认对应扩展是否发布 v8 兼容版，否则composer require会失败
composer.lock 文件被忽略会导致版本失控
有些团队把 composer.lock 加进 .gitignore，觉得“只要 composer.json 对就行”，结果不同人 composer install 出来的 ThinkPHP 小版本可能差两个 patch 号，某天突然 Db::table()->find() 返回 null 而不是空对象——其实是 v6.1.3 修复过这个行为，但有人装的是 v6.1.0。
-
composer.lock必须提交 Git，它是版本一致性的唯一凭证 - CI/CD 流程里必须用
composer install（不是require或update），否则构建环境无法复现本地行为 - 如果发现
vendor/和composer.lock不匹配，优先跑composer install --no-dev而不是删 vendor 重来
版本锁定不是设完 require 就一劳永逸的事，关键在 composer.lock 是否真实反映当前运行态，以及每次更新是否经过验证。很多人卡在“明明写了 6.1.0 却还是装了 6.2”，问题往往出在 lock 文件没更新或被覆盖了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
