RegisterService是服务注册入口，非自动执行；需App::initialize()显式调用，仅将服务提供者类名加入$app->services数组，不实例化也不调用register()，真正注册绑定逻辑在各ServiceProvider的register()方法中完成。
RegisterService 是服务注册的入口，不是自动执行的“魔法”
它本质是一个可选的初始化阶段，由 App::initialize() 显式调用，不会在框架启动时自动触发。如果你没看到服务被注册，大概率是漏掉了这一步，或者你误以为它像 boot() 那样会自动运行。
常见错误现象：App::make('SomeService') 报错 Class not found 或 Cannot resolve dependency，但类文件明明存在、命名也正确——问题往往出在服务根本没注册进容器。
- 它只负责把服务提供者类名（如
PaginatorService::class）加入$app->services数组，不实例化、不调用register() - 真正干活的是后续的
boot()：遍历$app->services，逐个$app->make($service)->register() - TP8 中
RegisterService通常作为系统初始化器（$app->initializers中的一项）被调用，位置在loadEnv()和load()之后、AppInit事件之前
register() 方法里干了什么？绑定、别名、单例三件套
每个服务提供者（比如 ValidateService）的 register() 方法，核心就是往容器里塞东西。不是“启动服务”，而是“告诉容器怎么造这个服务”。
典型操作示例（简化自 TP8 源码）：
立即学习“PHP免费学习笔记（深入）”；
public function register()
{
$this->app->bind('validate', ValidateFactory::class);
$this->app->singleton('think\Validate', ValidateFactory::class);
$this->app->alias('validator', 'validate');
}
-
bind()是弱绑定：每次make('validate')都新建实例（除非该类自己控制单例） -
singleton()是强绑定：首次make()后缓存，之后全走$instances，适合无状态工厂或全局配置对象 -
alias()是取小名：让$app->make('validator')等价于$app->make('validate')，提升使用便利性 - 注意：
bind()和singleton()的第一个参数是抽象标识（字符串或类名），第二个是具体实现（类名、闭包或对象），顺序不能反
为什么有些服务注册后还是用不了？路径和加载时机是关键
服务注册失败，80% 出在两处：类没自动加载，或注册逻辑被跳过。
- 确保服务提供者类文件在
composer autoload范围内，例如放在app/provider/下但没在composer.json的"autoload": {"psr-4": {...}}里声明 - 检查是否误删或注释了
App::initialize()中对RegisterService的调用——TP8 默认有，但定制入口时容易动到 - 第三方扩展包若依赖自动发现（如通过
extra.think-framework.providers），需确认其composer.json正确声明，且composer dump-autoload已执行 - 调试技巧：在
RegisterService::handle()开头加var_dump($this->app->services);，看目标服务类名是否已出现在数组里
RegisterService 和 boot() 不是一回事，别混着用
这是最容易混淆的点。注册（register）只是登记“谁可以造什么”，启动（boot）才是“让它们开始工作”。比如日志服务：
-
register()做的事：绑定'log'→LogFactory::class，绑定LoggerInterface::class→think\log\driver\File::class -
boot()做的事：调用LogFactory::create()实例化驱动，读取config/log.php初始化路径和级别，注册异常处理器 - 如果你在
register()里就尝试$this->app->make('log')->info(...)，大概率失败——此时配置还没加载完，驱动也未初始化
复杂点在于：register 阶段只能安全操作容器绑定，所有依赖配置、其他服务、请求上下文的逻辑，必须挪到 boot 或更晚阶段。这个边界一旦越界，就会出现“服务存在但无法用”的诡异状态。
