Service类的register()方法是唯一安全的绑定入口，框架在容器初始化早期自动调用，确保绑定时机可控、上下文确定；直接调用bind()易因容器未就绪导致注入失败。
Service类的register()方法是唯一安全的绑定入口
在ThinkPHP中，Service类不是用来直接调用bind()的地方，而是通过register()方法让框架在容器初始化早期自动执行绑定。这个方法被框架在应用启动时统一调用，上下文确定、时机可控；如果在__construct或boot()里调用bind()，可能因容器状态未就绪导致绑定失效。
常见错误现象：服务类里写$this->app->bind('logger', Logger::class)但控制器里Logger $logger注入失败，原因就是bind()执行太晚，类型解析阶段容器还没看到这条映射。
-
register()方法必须存在，且不能带参数（框架反射调用时不传参） - 不要在
boot()里重复绑定——它用于依赖已就绪后的初始化动作，比如监听事件、注册中间件 - 若只是简单绑定，可直接定义
public $bind = ['cache' => hinkcachedriverRedis::class];，框架会自动处理，无需手写register()
bind和singleton的区别直接影响对象生命周期
用bind()每次make()都会新建实例，用singleton()则只创建一次并复用。选错会导致意外状态共享或资源浪费。
典型场景：Redis连接适配器应singleton()，避免反复建连；而FormRequest这类临时验证对象适合bind()，保证每次请求隔离。
立即学习“PHP免费学习笔记（深入）”；
将 .eth 名称解析为以太坊地址，反之亦然。适用于用户提供 .eth 名称（如“发送给 vitalik.eth”）、显示地址时展示 ENS 名称、查询 ENS 档案，或帮助注册、续期、管理 .eth 名称。
-
$this->app->bind('sms_client', AliyunSmsClient::class)→ 每次注入都 new 一个新客户端 -
$this->app->singleton('redis_pool', RedisPool::class)→ 全局只初始化一次连接池 - 别混用：对同一个键名先
bind再singleton，后者会覆盖前者，但已有实例不会自动销毁
服务提供者没生效？检查composer.json和service:discover
自定义包里的Service类不会自动被加载，ThinkPHP只认composer.json里声明的extra.think.providers路径，且必须执行php think service:discover生成缓存。
错误现象：修改了ServiceProvider里的bind逻辑，但容器还是返回旧对象——大概率是缓存没刷新，或者composer.json里路径拼错。
- 确认
composer.json中"extra": {"think": {"providers": ["Vendor\Package\ServiceProvider"]}}反斜杠是双写（JSON字符串要求） - 执行
composer dump-autoload确保类能被class_exists()识别 - 运行
php think service:discover，它会扫描所有extra.think.providers并写入runtime/service.php，跳过这步等于没注册
别在common.php或命令handle()里盲目bind
common.php没有应用上下文，Container::getInstance()此时拿到的是裸容器，后续框架初始化会覆盖掉你绑的内容；命令行handle()里bind()只对当前命令生效，不影响HTTP请求流程。
真实踩坑案例：有人在handle()开头写Container::getInstance()->bind('cache_adapter', Redis::class)，结果Web端还是走FileCache——因为两个请求走的是不同容器实例。
- 全局绑定必须进
Service::register()或app/provider.php数组 -
app/provider.php适合轻量级绑定，比如接口→实现映射：'appcacheCacheInterface' => 'appcacheRedisCache' - 绝对不要在
common.php里调用bind()，该文件加载时机早于App实例创建，绑定必然丢失
service:discover到Service::register()再到App实例化，每一步断掉，绑定就成空谈。 
