phalcon长驻服务中单例易致状态污染，应将用户上下文、日志处理器等有状态对象设为非共享（set），仅无状态资源如db连接可shared；协程场景需手动传参或用coroutine::getcontext()隔离；动态注册服务后须调用remove清理。
Phalcon 的 DI 容器默认支持单例（shared）绑定，这在 Web 请求场景下很合理——每个请求新建容器，状态天然隔离。但用在长驻服务（如 CLI 启动的常驻进程、WebSocket 服务器、队列 worker）时，单例实例会跨请求/跨连接长期存活，若其内部持有用户 ID、会话数据、数据库事务状态、缓存键前缀等动态上下文，就会发生状态污染：后一个请求读到前一个请求残留的数据。
核心问题不在“单例本身”，而在于把本该按请求/协程/连接生命周期管理的对象，错误地注册成了全局单例。
识别哪些单例容易污染
以下类型的服务一旦设为 shared，极易出问题：
- 用户上下文管理器（含
userId、tenantId、authToken等字段） - 请求级日志处理器（带 traceId、requestId、上下文标签）
- 数据库查询构建器（如自定义 QueryBuilder，内部缓存了
where条件或orderBy） - 缓存客户端封装类（若内部硬编码了
prefix或tag） - 表单验证器或规则集（若保存了上一次验证失败的字段状态）
✅ 正确做法：这些对象应是 瞬时（non-shared） 或 作用域绑定（scoped），每次需要时新建，用完即弃。
Phalcon 中避免污染的实操方案
Phalcon 4+ 的 DI 支持 setShared() 和 set() 两种注册方式：
// ❌ 危险：全局共享，状态跨请求残留
$di->setShared('userContext', function () {
return new UserContext(); // 内部有 $this->userId = null;
});
// ✅ 安全：每次 get() 都新建实例
$di->set('userContext', function () {
return new UserContext();
});
若必须复用某些昂贵资源（如 PDO 连接、Redis 客户端），可拆分职责：
// ✅ 共享底层连接（无状态）
$di->setShared('db', function () {
return new \Phalcon\Db\Adapter\Pdo\Mysql($config);
});
// ✅ 每次新建查询器（有状态）
$di->set('queryBuilder', function () use ($di) {
return new CustomQueryBuilder($di->get('db'));
});
协程或连接级隔离（Workerman/Swoole 场景）
Phalcon 原生不提供协程上下文，但在 Workerman/Swoole 中运行时，需主动剥离请求语义：
- 不要用
Di::getDefault()->get('userContext')全局取； - 改为在
onMessage/onOpen回调中显式创建并传入：$userCtx = new UserContext($connection->uid ?? null); $handler->handle($data, $userCtx);
- 或借助 PHP 8.0+ 的
Coroutine::getContext()存协程局部数据：Coroutine::getContext()['user_id'] = $uid; // 在同一协程内任意位置取 $uid = Coroutine::getContext()['user_id'] ?? null;
⚠️ 注意：
Coroutine::getContext()仅在协程环境有效；传统回调（如非协程模式的onMessage）仍需手动传参或用$connection->id做 WeakMap 映射。
清理与重置机制（防内存泄漏）
长驻进程中，DI 容器不会自动清空。若你动态注册了服务（比如根据租户加载不同配置），务必手动清理：
// 注册临时服务（如租户专属缓存）
$di->set("cache_{$tenantId}", function () use ($tenantId) {
return new TenantCache($tenantId);
});
// 使用完毕后及时解绑（避免累积）
$di->remove("cache_{$tenantId}");
也可在每次处理完一个完整业务单元（如一次 WebSocket 消息闭环）后，重建轻量 DI 实例：
$localDi = new FactoryDefault();
$localDi->set('db', fn() => $globalDb); // 复用连接
$localDi->set('logger', fn() => new RequestLogger());
这样既保性能，又保隔离。
不复杂但容易忽略。关键就三点：
区分状态有无 —— 有状态对象绝不 shared；
分清生命周期 —— 请求/协程/连接级对象，就该按对应粒度创建；
主动清理边界 —— 动态注册必配 remove，长驻进程不能靠 GC 猜。
