必须用composer create-project安装ThinkPHP6，因topthink/think是项目模板而非普通库，require仅装入vendor不生成app/public/.env等骨架文件，导致Class 'thinkApp' not found。
ThinkPHP 扩展不能靠 composer require 往空项目里“硬塞”，必须先用 composer create-project 搭好完整骨架，否则连 thinkApp 都找不到——这不是配置问题，是项目结构缺失导致的自动加载失效。
为什么 composer require topthink/think 一定失败
ThinkPHP 6+ 不是普通 Composer 库，而是“应用即框架”模型。执行 composer require topthink/think 只会把源码放进 vendor/topthink/framework，但不会生成 app/、public/、.env，也不会运行初始化脚本。结果就是：
-
vendor/autoload.php存在，但没注册think根命名空间 -
php public/index.php报Class 'thinkApp' not found -
php think命令直接提示“command not found”或解析失败 - 验证方式：
php -r "require 'vendor/autoload.php'; var_dump(class_exists('thinkApp'));"返回bool(false)
正确安装 ThinkPHP 并管理扩展的流程
所有操作必须在项目根目录（含 composer.json、public/、think 文件）下进行：
- 新项目：用
composer create-project topthink/think myapp（默认 TP8）或composer create-project "topthink/think:^6.1" myapp（TP6 兼容 PHP 7.2+） - 加扩展：用
composer require topthink/think-captcha或带版本约束的composer require topthink/think-queue:^8.0 - 启用扩展：检查
config/app.php的'providers'数组是否包含对应服务提供者类，如thinkcaptchaCaptchaService::class；若无则手动添加 - 补配置文件：部分包（如
think-queue）不自动发布配置，需手动从vendor/topthink/think-queue/config/queue.php复制到项目config/目录下
composer install 和 composer update 到底该用哪个
两者行为完全不同，误用会导致环境不一致：
立即学习“PHP免费学习笔记（深入）”；
-
composer install：严格按composer.lock安装，版本精确、速度快，**上线部署和 CI/CD 必须用它** -
composer update：按composer.json重新解析依赖树，升级到满足约束的最新兼容版，**仅限本地开发或修复已知漏洞时使用** - 只更新单个包：
composer update topthink/think-captcha，避免全量刷包引发隐性冲突 -
composer.lock必须提交到 Git，不提交 = 每次install都是盲装，团队协作必出问题
自定义类库和第三方 SDK 的 autoload 配置
ThinkPHP 默认只加载 app/ 下的 PSR-4 命名空间，其他目录需手动声明：
- 自定义服务类放
app/service/，在composer.json中加："autoload": { "psr-4": { "app\service\": "app/service/", "app\utils\": "app/utils/" } } - 改完后必须运行
composer dump-autoload生效，否则类仍找不到 - 第三方 SDK（如
overtrue/wechat）直接composer require overtrue/wechat即可，Composer 会自动处理 autoload - 别把运行时依赖（如
monolog/monolog）错放到require-dev，否则线上日志直接失效
最容易被忽略的是服务提供者的注册和配置文件的手动复制——很多扩展包装完了就以为能用，结果运行时报“undefined service”或“missing config”，其实只是卡在这两步。不是框架不兼容，是机制没走全。
