Service Provider 必须实现 think\Service 接口，register() 中仅允许 bind/singleton 声明式绑定，禁止业务逻辑；配置需确保前置加载，绑定顺序由 config/app.php 的 providers 数组决定，实例化延迟至 Container::get() 时触发。
Service Provider 必须实现 think\Service 接口
不实现这个接口，think\Container 就不会识别它为合法服务提供者，php think service:discover 也不会扫描到。接口要求必须有 register() 方法，且该方法内只能做绑定操作（bind() 或 singleton()），不能执行任何业务逻辑或初始化动作。
常见错误是把数据库连接、缓存实例化写在 register() 里——此时容器尚未完成初始化，$this->app->get('config') 可能返回 null 或抛出异常。
-
register()中只调用$this->app->bind('sms', AliyunSmsClient::class)这类声明式绑定 - 真正实例化应推迟到首次
Container::get('sms')时，由容器自动触发反射或闭包 - 若需提前加载配置，改用
$this->app->config->get('sms')，但确保配置文件已加载（如在config/app.php的providers数组前已加载）
config/app.php 的 providers 数组决定加载顺序
ThinkPHP 6+ 启动时按 providers 数组顺序依次调用每个 Service Provider 的 register()，顺序直接影响绑定优先级和依赖可用性。比如你要绑定 RedisCache，但它依赖 redis 配置，那提供 redis 配置的 Provider（如 think\provider\ConfigProvider）必须排在前面。
开发期可临时手动添加自定义 Provider 到该数组末尾，但上线前务必执行 php think service:discover 生成缓存，否则 Composer 自动发现机制失效，新 Provider 不会被加载。
立即学习“PHP免费学习笔记（深入）”；
- 不要在
common.php或bootstrap.php里调用bind()—— 上下文不确定，可能被后续 Provider 覆盖 - 多个 Provider 绑定同一标识（如都 bind
'cache'），后加载的会覆盖前一个 - 若需条件绑定（如开发环境用 FileCache，生产用 RedisCache），应在
register()内用$this->app->isDebug()判断，而非靠数组顺序
绑定后必须用 Container::get() 获取，不能 new
Service Provider 注册的只是“契约”，不是实例。直接 new AliyunSmsClient() 会绕过容器，导致依赖无法注入、单例失效、配置不可达。所有消费方必须通过容器获取：
// 正确：走容器解析，自动注入构造函数依赖
$sms = Container::get('sms');
// 错误：完全脱离容器，$sms->send() 里用的 Db 或 Config 可能是 null
$sms = new AliyunSmsClient();
更隐蔽的坑是控制器里写 public function __construct(AliyunSmsClient $sms) 却没生效——因为默认控制器不走容器创建。必须在 providers 数组中显式注册该控制器类，或改用 Action 方法参数注入（public function index(AliyunSmsClient $sms)）。
闭包绑定要小心生命周期和参数延迟
在 register() 里绑定闭包时，闭包本身不会立即执行，但它的参数签名会影响容器解析时机。例如：
$this->app->bind('cache', function () {
return new RedisCache(config('cache.redis'));
});
这段代码会在第一次 Container::get('cache') 时执行，但 config('cache.redis') 是启动时就求值的——如果 config 尚未加载，就会报错。正确做法是把依赖声明为闭包参数：
$this->app->bind('cache', function (Container $container) {
return function () use ($container) {
return new RedisCache($container->get('redis'));
};
});
这样 $container->get('redis') 才会在真正需要实例时才调用，避免启动阶段失败。
闭包绑定最易忽略的是作用域污染：闭包里引用了外部变量（如 $config），而该变量在后续请求中被修改，会导致所有后续 get('cache') 返回错误实例。一律用 $container->get() 拉取依赖，别捕获外部状态。
