Hyperf协程模型不能自动解决资源浪费，必须切断进程级依赖、改写阻塞调用、隔离上下文；$_GET等全局变量失效是设计使然，需通过RequestInterface或Context::get()获取请求数据，static单例和阻塞函数将导致协程污染与QPS下降。
直接换用 Hyperf 协程模型不能自动解决资源浪费问题，反而可能因沿用 PHP-FPM 习惯写法导致更严重的协程污染、连接错乱或 QPS 不升反降。关键不是“单进程”本身，而是你是否切断了进程级依赖、改写了阻塞调用、隔离了上下文。
$_GET、$_POST、$_SERVER 全部失效，不是 bug 是设计
协程里没有全局请求变量——它们是进程级共享的，多个协程交叉读写会拿到上一个请求残留的数据。比如你在中间件里直接读 $_GET['id']，极大概率返回的是前一个用户的参数。
- 控制器中必须通过类型提示获取：在方法参数写
RequestInterface $request，再调$request->get('id') - 工具函数里要用
Context::get(ServerRequestInterface::class)显式提取当前协程的请求对象 - 绝对不要在
__construct()或 static 方法里缓存$_GET，协程切换后值就不可信
static 单例 = 协程污染源，尤其 DB/Redis/HTTP 客户端
传统 private static $instance 在协程下变成所有请求共用一个实例，A 用户的数据库连接被 B 用户事务覆盖，Redis 连接被 C 用户 select 切库干扰，MySQL server has gone away 就是典型症状。
- 服务类一律交给 DI 容器管理：
ApplicationContext::getContainer()->get(YourService::class)，Hyperf 默认按协程生命周期创建新实例 - 若需手动绑定上下文数据，用
Context::set('user_id', 123)+Context::get('user_id')，别碰static - 连接类（如
Hyperf\DbConnection\Db）已内置连接池和协程隔离，直接new且存static会绕过池管理，直接报废
sleep()、file_get_contents()、curl_exec() 必须替换
这些函数一执行，整个协程挂起，其他并发请求全部卡住——不是慢，是“集体冻结”。Hyperf 启动后 QPS 下跌，90% 源于此。
立即学习“PHP免费学习笔记（深入）”；
-
sleep(1)→ 改用co::sleep(1.0)（单位秒，支持浮点） -
file_get_contents('http://api.com')→ 改用Hyperf\HttpClient\Client::get() -
curl_exec($ch)→ 改用Hyperf\Guzzle\CoroutineHandler包装 Guzzle，或直接用HttpClient - 任何第三方 SDK 若未声明协程兼容，先查它底层是否调了
curl_exec或fread；没改写就别接入
连接池配置不匹配事务，等于白开协程
Hyperf 默认启用连接池，但 DB::transaction() 如果没对齐池行为，会出现“刚插入查不到”“回滚失败”，表面是 ORM 问题，实际是连接复用错乱。
- 数据库配置里必须显式设置
pool.max_connections≥ 预估并发峰值，例如 500 并发至少设 60+，否则池耗尽后请求排队等连接 - 事务内所有操作必须复用同一个连接，确保
beginTransaction()和commit()走同个连接句柄——Hyperf 的Db组件默认做到，但自定义 PDO 实例则不行 - Redis 连接池同理：
pool.max_connections要与业务最大并发数匹配，否则get()+set()可能跨连接，丢失原子性
协程不是魔法开关，它是把双刃剑：切得准，资源利用率翻倍；切不准，比多进程还难 debug。最常被忽略的点是——你以为改了服务器类型，其实只是换了运行时，代码逻辑仍活在进程思维里。
