根本原因是post-autoload-dump钩子未配置或被跳过，导致php think service:discover未执行；需在composer.json的scripts中显式声明"post-autoload-dump": ["@php think service:discover"]，并确保未使用--no-scripts等禁用选项。
根本原因不是脚本写错了，而是 Composer 的 post-autoload-dump 钩子压根没触发 php think service:discover —— 这个命令不会自动运行，除非你明确配置了它。
为什么 composer install 或 require 后没执行 service:discover
ThinkPHP 6/8 的服务发现不依赖 Composer 自动调用；它只在两个场景下被触发：一是你手动运行 php think service:discover，二是你在 composer.json 的 scripts 里显式声明了该命令，并且该钩子未被跳过。
常见错误现象：composer require topthink/think-captcha 成功，但 use think\captcha\Captcha 报 ClassNotFoundException；runtime/service.php 文件不存在或为空。
- 检查项目根目录下的
composer.json是否包含类似如下配置（缺则补）：
"scripts": {
"post-autoload-dump": [
"@php think service:discover"
]
}
- 确认没有全局或项目级禁用钩子：比如
composer install --no-scripts、COMPOSER_NO_INTERACTION=1环境变量、或 CI 脚本中加了--no-plugins - Windows 用户注意：Git Bash 下
php命令可能找不到，导致脚本静默失败；建议改用 PowerShell 或 CMD 执行composer dump-autoload触发钩子
php think service:discover 执行报错或无输出
这条命令失败，通常不是权限或路径问题，而是框架初始化阶段就卡住了——比如容器未就绪、App 实例缺失、或某个服务提供者里的 register() 方法提前抛出异常。
立即学习“PHP免费学习笔记（深入）”；
- 确保当前工作目录是 ThinkPHP 项目根目录（含
think可执行脚本） - 运行前先验证基础可用性：
php think应输出命令列表；若报Class 'think\App' not found，说明vendor/autoload.php没加载成功，先解决自动加载 - 若报
Call to a member function request() on null（常见于Session.php），说明框架核心组件（如Request、App）尚未注册进容器——此时应检查config/app.php中默认的providers数组是否被意外清空或覆盖 - 临时绕过：直接在
config/app.php的'providers'数组末尾追加你的服务提供者类，例如Vendor\Package\ServiceProvider::class，避免依赖自动发现
开发期如何跳过缓存文件，让服务提供者立即生效
runtime/service.php 是服务发现的缓存结果，但开发时频繁修改服务提供者类名或绑定逻辑，等它自动生成反而拖慢迭代。最直接的方式是绕过它。
- 删除
runtime/service.php文件（如有），然后手动把服务提供者类写入config/app.php的'providers'数组中 - 确保该类已通过
composer dump-autoload注册到自动加载器（尤其新增类后必做） - 服务提供者类必须实现
think\Service接口（注意不是Psr\Container\ServiceProviderInterface），且register()方法内使用$this->app->bind()或$this->app->singleton()绑定，不能直接new - 命名空间大小写敏感：Windows 下因文件系统缓存，
Vendor\Package\Providers\MyService和实际文件名myservice.php不匹配会导致类找不到，务必保持一致
真正容易被忽略的是：服务提供者类本身能否被 ClassLoader 正确定位，和 service:discover 是否执行成功，其实是两个独立问题。前者失败，后者再怎么跑也白搭。
