Hyperf的“单例”指DI容器中同一服务每次get()返回同一对象引用,但该对象在Worker进程内常驻且协程间共享,其属性不随协程切换隔离,故不能存储请求级数据;正确做法是用Context::set/get或RequestInterface等协程绑定机制。

Hyperf里“单例”不是指一个进程只有一个实例
Hyperf 的“单例”是 DI 容器注册时的生命周期策略,即 Container::set($id, $definition, true) 中第三个参数为 true(默认行为),表示该服务在容器中只绑定一次,每次 get() 或注入都返回**同一个对象引用**——但这个“同一对象”仅对当前 Worker 进程有效,且不随协程切换重置。
关键点在于:它不等于传统 PHP-FPM 下的“进程内唯一”,更不等于“线程安全”或“协程隔离”。你写 protected $user_id = 123,下一个协程进来读到的还是 123,哪怕它压根没设过。
- Controller、Service、Middleware 默认都是单例绑定
- 单例对象在 Worker 启动时初始化,常驻内存,不会因请求结束而销毁
- 协程间共享对象实例,但协程上下文(Context)是隔离的——而对象属性不属于 Context
为什么用单例却不能存请求数据
因为单例对象的成员变量是进程级共享的,不是协程级隔离的。Hyperf 没有自动帮你把 $this->requestId 绑定到当前协程上下文,它就只是个普通属性。
常见踩坑写法:
class UserService
{
protected array $cache = [];
<pre class="brush:php;toolbar:false;">public function getUser(int $id): array
{
if (!isset($this->cache[$id])) {
$this->cache[$id] = $this->db->fetchOne('SELECT * FROM user WHERE id = ?', [$id]);
}
return $this->cache[$id];
}}
这段代码在并发下会污染缓存:协程 A 存了 $this->cache[1],协程 B 可能直接读到并返回错误数据。
- 所有
protected/private属性都共享,包括数组、对象、标量 -
static变量更危险,全 Worker 共享,跨协程、跨请求无任何边界 - 构造函数里传参初始化也不能解决,因为对象复用,构造只执行一次
那数据库连接也是单例,为什么不会串
因为 Hyperf\Db\Connection 是“无状态单例”:它本身不保存查询结果、用户 ID、分页偏移等业务数据;真正的连接由底层连接池按协程 ID 分配物理连接,execute、query 等方法内部会自动绑定当前协程上下文。
换句话说:你调用的是同一个 Connection 对象,但每次 SQL 执行走的是不同物理连接,且事务、最后插入 ID、错误信息等都通过 Swoole 协程上下文隔离。
- 连接池管理的是物理连接,不是 Connection 实例
- DI 容器返回的 Connection 实例是代理,实际操作委托给协程绑定的连接资源
- 如果你手动在 Connection 类里加
$this->lastQuery,一样会串数据
真正该用什么存请求级数据
必须显式使用协程上下文(Hyperf\Context\Context)或框架提供的契约接口,比如 RequestInterface、ResponseInterface,它们天然绑定当前协程。
示例:
// ✅ 正确:绑定到协程上下文
Context::set('user_id', $userId);
<p>// ✅ 正确:从 Request 对象取(它本身也基于 Context 封装)
$request->getAttribute('user_id');</p><p>// ❌ 错误:存在 Service 属性里
$this->currentUserId = $userId;</p>
- 不要依赖“类实例唯一”来推导“数据安全”,Hyperf 里唯一不安全的就是你以为安全的地方
- Context::get/set 性能开销极低,Swoole 底层已优化为数组哈希查找
- 如果用了 AOP 或中间件,务必确认它们是否清除了自定义 Context key,否则可能残留上一请求的数据
Hyperf 的单例本质是容器生命周期策略,不是数据隔离机制。最容易被忽略的,就是把“对象复用”和“数据安全”画等号——而真实情况是:对象越复用,越要警惕属性污染。











