Hyperf新手常见误区是误用Laravel思维，未理解协程生命周期、服务常驻和DI容器行为变化三层逻辑，导致阻塞调度、状态污染和单例滥用。
Hyperf 是基于 Swoole 的高性能协程 PHP 框架，新手容易把它当成“Laravel 替代品”来用，结果踩进架构设计的深坑。核心误区不是语法不会，而是没理解 协程生命周期、服务常驻、依赖注入容器行为变化 这三层底层逻辑。
把 Laravel 思维直接搬进 Hyperf
比如在控制器里 new 一个数据库连接、手动 require 配置文件、或在方法里写 sleep(3) —— 这些在 Laravel 中无感的操作，在 Hyperf 里会阻塞整个协程调度，拖垮并发能力。Hyperf 的请求是协程内非阻塞执行的，所有 I/O 必须走协程化驱动（如 hyperf/database 内置的协程 MySQL 客户端）。
- 避免使用 sleep()、file_get_contents()、原生 PDO 等同步阻塞调用
- 配置统一走 config/autoload/ + ConfigInterface 注入，不要运行时 require
- DB 查询必须用 Db::table() 或 Eloquent（需启用协程版模型）
忽略服务常驻带来的状态残留问题
Hyperf 进程启动后长期运行，全局变量、静态属性、单例对象不会随请求结束而销毁。新手常把用户 token、临时数据存到 static 属性里，导致下一个请求拿到上一个用户的脏数据。
- 禁止在类中用 public static $user 缓存请求上下文
- 需要跨协程传递数据，用 Coroutine::getContext() 或 ApplicationContext::getContainer()->get(RequestInterface::class)
- 中间件里修改的 Request 对象，要确保不污染后续协程（例如 clone 或用独立上下文）
滥用 @Inject 和容器单例生命周期
@Inject 默认注入的是容器中的单例（Singleton），但很多新手以为每次请求都会新建实例。比如注入一个含属性的 Service 类，第一次请求设了 $this->uid = 1001，第二次请求进来发现还是 1001 —— 因为它根本没重建。
- 需要每次请求隔离的对象（如带用户态的 Service），改用 @Inject(scope=ScopeEnum::PROTOTYPE)
- 数据库连接、Redis 客户端等底层资源类，才适合 Singleton；业务逻辑类优先考虑 Prototype
- 查看实际绑定方式：看 Log::error()）
- defer 函数里不要做耗时操作，更不能再起协程（易引发上下文丢失）
- 全局异常处理器（ExceptionHandler）只捕获主协程异常，子协程需单独兜底
