Hyperf 的常驻内存模型是彻底替换运行范式而非优化初始化——初始化仅一次且所有请求共享内存，传统 Laravel/ThinkPHP 写法因依赖请求隔离会引发数据污染；需区分进程级与协程级生命周期，数据库配置等可保留，Redis 实例、用户 ID 等必须改用上下文或连接池；协程安全方案包括 Context 存储、瞬态注入和连接池管理。
Hyperf 的常驻内存模型不是“优化传统框架初始化”的手段，而是彻底替换运行范式——它不解决“每次请求都初始化”的问题，而是让初始化只发生一次，之后所有请求共享这个内存空间。直接复用传统写法会立刻污染数据。
为什么不能把 Laravel/ThinkPHP 写法直接搬进 Hyperf
传统框架依赖“请求生命周期隔离”，每个请求都是全新进程或线程，类属性、静态变量、单例对象天然互不干扰；Hyperf 的 Worker 进程常驻，static $instance、private $cache、public $userId 全部变成跨请求共享状态。
- 错误现象：并发请求 A 登录用户 1001，B 登录用户 1002，但 B 的响应里返回了 A 的订单列表
- 根本原因：数据库连接、Redis 客户端、日志实例等被存为类静态属性或单例，协程间直接读写同一块内存
- 典型代码：
class UserService { private static $instance; public static function getInstance() { return self::$instance ??= new static(); } }—— 在 Hyperf 中这就是污染源
哪些传统初始化逻辑必须重写
不是所有初始化都要删掉，而是要区分“进程级”和“协程级”生命周期：
-
config/autoload/database.php加载的数据库配置、连接池参数 → 保留，这是进程级共享的合理部分 - 构造函数里
$this->redis = RedisFactory::getInstance()→ 必须删，改用$this->redisPool->get()每次取新连接 -
__construct()中赋值$this->userId = $request->input('uid')→ 危险，应改为方法参数传入或从上下文获取：Context::get('user_id') - 中间件里
Log::info('start')调用全局 Logger 实例 → 若该实例缓存了 trace_id，会导致日志混写，必须改用上下文注入或协程本地日志实例
协程安全的初始化替代方案
真正需要“每次请求初始化”的东西，得靠协程上下文或容器瞬态绑定来实现：
- 用
Context::set('user', $user)+Context::get('user')替代类属性存储用户信息 - 依赖注入时显式声明非共享：
@Inject(shared=false) private DbConnection $db;或$container->make(DbConnection::class, [], true) - 数据库操作统一走连接池：
$conn = $this->pool->get(); try { ... } finally { $this->pool->put($conn); } - 自定义初始化逻辑（如权限检查）放到中间件或控制器方法内，避免塞进构造函数
最容易被忽略的是：你以为只是“初始化一次更快”，实际上你正在把整个请求上下文拖进一个共享内存陷阱里。协程不是线程，没有自动隔离；它靠的是开发者对生命周期边界的清醒认知——哪部分该在进程启动时做，哪部分必须每次请求重建，界限模糊的地方就是 bug 高发区。
