ThinkPHP Service里绑定单例服务怎么写-ThinkPHP-PHP中文网

Service类注册为单例须调用app()->singleton()显式绑定，而非bind()；若依赖其他对象，需在闭包中用$app->make()获取，确保生命周期统一，否则子对象仍会重复创建。

thinkphp service里绑定单例服务怎么写

ThinkPHP 的服务容器默认每次 app()->get() 都会新建实例，要绑定单例，必须显式调用 bind() 或 singleton() 方法，且推荐在应用启动阶段（如 app/common/service.php 或 app/bootstrap.php）完成注册。

常见错误是直接在控制器里 new 一个 Service 类再塞进容器，或者用 bind() 但没传闭包——这会导致每次获取仍是新实例。

正确写法：用 app()->singleton('UserService', function ($app) { return new UserService($app->make(UserModel::class)); });
更简洁方式（5.1+）：在 app/common/service.php 中返回数组，键为服务名，值为闭包或类名字符串：return ['UserService' => UserService::class]; —— 注意：这种方式仅在配置了自动单例解析时生效（需确认 container.php 中 'auto_bind' => true）
若 Service 类依赖其他对象（如模型、缓存），务必在闭包中通过 $app->make() 获取，避免硬编码 new

bind() 是“绑定接口到实现”，不控制生命周期；singleton() 才真正保证全局唯一实例。两者语义和行为完全不同，混用会导致预期外的重复初始化。

ENS (Ethereum Name Service)

将 .eth 名称解析为以太坊地址，反之亦然。适用于用户提供 .eth 名称（如“发送给 vitalik.eth”）、显示地址时展示 ENS 名称、查询 ENS 档案，或帮助注册、续期、管理 .eth 名称。

下载

app()->bind(UserServiceInterface::class, UserService::class) → 每次 app()->get(UserServiceInterface::class) 都 new 一个新 UserService
app()->singleton(UserServiceInterface::class, UserService::class) → 第一次 get 时创建，后续全返回同一实例
如果接口没被提前 bind，直接 singleton(UserService::class) 也有效，但无法通过接口类型获取，灵活性下降

不会。单例只作用于你注册的那个 Service 实例本身，它内部持有的依赖对象（比如 UserModel）是否单例，取决于这些依赖自身是如何注册或创建的。

如果你在 singleton 闭包里写 new UserModel()，那每次 Service 初始化都会 new 新模型 —— 这通常不是你想要的
应该写 $app->make(UserModel::class)，前提是 UserModel 本身也已注册为单例（默认情况下 ThinkPHP 的模型类不是单例）
想让模型也复用，得额外加一句：app()->singleton(UserModel::class, UserModel::class)，否则即使 Service 是单例，里面每次调用 $this->model = new UserModel() 仍会生成新对象

最直接的办法是加日志或断点，在 Service 构造函数或某个方法开头打个 echo spl_object_hash($this) . "\n";，然后在两个不同控制器里调用它，看输出的 hash 是否一致。

如果 hash 不同，说明没走单例路径，检查是否误用了 bind()、是否闭包里漏了 return、是否注册时机太晚（比如在中间件或控制器里才注册）
注意：命令行和 HTTP 请求是两个独立容器实例，不能跨进程验证单例性；要在同一请求生命周期内验证
也可以用 app()->has('UserService') 和 app()->get('UserService') === app()->get('UserService') 在同一个请求中做判断

实际项目里最容易忽略的是依赖链的单例穿透——Service 是单例了，但它 new 出来的子对象不是，结果状态还是不共享。得一层层确认关键依赖是否也进了容器单例池。