provider.php 是容器绑定配置入口，仅负责接口与实现类的映射，不执行初始化或逻辑；service.php 非 TP6 官方文件，无效；真正注册 Service 应在服务提供者中完成。
provider.php 是容器绑定配置入口，不是服务注册文件
很多人误以为 provider.php 是用来“注册 Service 类”的地方，其实它只是容器的「接口→实现类」映射表。它不负责初始化、不执行逻辑、不处理生命周期——只做一件事：告诉容器「当有人要 app()->make(SomeInterface::class) 时，该返回哪个具体类的实例」。
常见错误是往里面塞一堆 new XxxService() 或调用 app()->bind() 方法，这不仅多余，还会在框架启动早期破坏容器状态。
-
provider.php必须返回一个关联数组，键是接口或类名，值是具体类名（字符串）或闭包 - 若要强制单例，必须显式用
app()->singleton()在服务提供者（如AppServiceProvider）里做，provider.php本身不支持 singleton 语法 - 不推荐在
provider.php中绑定具体类到自身（如MailService::class => MailService::class），这失去接口抽象意义，也阻碍 mock 和替换 - 环境差异大的绑定（如开发用
LogMailService，生产用SMTPMailService）应通过配置驱动，而不是硬写在provider.php里
service.php 不是 TP6 官方约定文件，放了也无效
TP6 没有 service.php 这个标准配置文件。你在项目里手动建一个 app/service.php 或 config/service.php，框架根本不会自动加载或识别它——既不会被容器读取，也不会触发任何注册行为。
这个误解常来自 Laravel 风格的命名习惯，或者把「Service 类的存放目录」和「服务配置文件」混为一谈。
立即学习“PHP免费学习笔记（深入）”；
- Service 类本身应放在
app/service/目录下，并确保该路径已加入composer.json的autoload.psr-4（例如"app\service\": "app/service/"），然后运行composer dump-autoload - 如果想让某个 Service 被容器自动解析（比如支持类型提示注入），必须通过接口绑定（
provider.php）或服务提供者（AppServiceProvider::register()）显式声明 - 别指望靠文件名触发机制：叫
xxxService.php不代表它会被自动注册，TP6 不扫描文件名
真正该注册 Service 的地方是服务提供者（ServiceProvider）
需要控制初始化时机、依赖顺序、条件加载或生命周期策略（比如非单例、带 Request 上下文）的 Service，必须放进自定义的服务提供者里，而不是塞进 provider.php 或幻想靠 service.php 自动生效。
例如订单锁库存服务依赖当前请求参数，就不能设为单例；又比如邮件服务需根据 config('mail.driver') 动态选择实现类——这些逻辑只能在 register() 或 boot() 方法里写。
- 新建
app/provider/OrderLockServiceProvider.php，继承thinkServiceProvide - 在
register()中用$this->app->bind()或$this->app->singleton()绑定 - 在
app/provider.php的返回数组中加入该提供者类名，才能被框架发现并加载 - 注意：服务提供者里的
register()执行时，容器尚未完成全部初始化（如Request实例还没绑定），要用boot()做依赖已就绪的操作
容易被忽略的关键点：provider.php 的加载时机早于应用初始化
provider.php 是在框架最开始阶段就被 thinkContainer 加载的，此时 app 实例甚至还没完全构建好——Request、Config、Db 等核心对象都不可用。所有依赖这些对象的初始化逻辑，绝不能放在 provider.php 返回的数组值里（比如闭包中调用 config('database.default') 会报错）。
这也是为什么工厂模式必须收口到服务提供者里：你没法在 provider.php 里安全地读配置、判断环境、创建带上下文的实例。看似省事的写法，上线后大概率在并发或 CLI 场景下出诡异问题。
