Hyperf 的 Database 和 Redis 客户端能“同步写法、异步执行”，是因为基于 Swoole 协程 Hook 劫持 socket 系统调用，自动让出控制权并唤醒协程，Hyperf 封装了协程驱动客户端，API 保持 Laravel 风格（如 DB::select()、$redis->get()），内部全程协程化，无需改业务逻辑或写 yield/await，前提是运行在 Swoole/Swow 协程模式且客户端启用协程驱动（Hyperf 默认开启）。
Hyperf 的 Database 和 Redis 客户端为什么能“同步写法、异步执行”？
因为它们不是直接调用 PHP 原生扩展（如 mysqli 或 redis 扩展），而是基于 Swoole 协程 Hook + 封装的协程驱动客户端。Swoole 在底层劫持了 socket 系统调用（如 connect、read、write），当遇到阻塞 IO 时，自动让出当前协程控制权，调度其他协程运行；IO 完成后唤醒原协程继续执行。Hyperf 的 Database 和 Redis 组件在此基础上做了适配封装，暴露的 API 保持与 Laravel 风格一致（如 DB::select()、$redis->get()），但内部全程走协程路径。
关键点在于：你不需要改业务逻辑，也不需要写 yield 或 await，只要在协程环境里调用，就自动协程化。前提是：服务必须运行在 Swoole（或 Swow）协程模式下，且客户端已启用协程驱动（Hyperf 默认开启）。
max_connections 和 min_connections 设多少才不翻车？
这两个参数直接影响连接池容量和冷启动表现，设错会导致连接耗尽或资源浪费：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
min_connections不建议设为 0 —— 即使没请求，也至少保留 1~2 个空闲连接，避免首请求触发建连延迟 -
max_connections要结合 DB 实例最大连接数（如 MySQL 的max_connections）来定，通常按Worker 进程数 × 每进程并发请求数 × 1.2估算，再留 20% 余量；例如 8 个 Worker，每个处理 50 并发，建议设为 480～600 - 若设得过高（比如 >1000），而 MySQL 实例只允许 500 连接，会触发
Too many connections错误，且错误日志中不会直接提示是连接池超限，而是表现为随机连接失败 - 生产环境务必监控
pool.status（可通过hyperf:pool-status命令查看），重点关注used和wait数值；wait > 0说明已有协程在排队等连接，是扩容信号
Redis 客户端事务（multi）和管道（pipeline）在协程下怎么用才安全？
Hyperf 的 Redis 客户端支持协程版 multi 和 pipeline，但要注意它们不是“全局共享”，而是绑定到当前协程获取的连接实例上：
- 每次
$redis->multi()都会从连接池取出一个连接，并在其上开启事务；事务结束（exec或discard）后该连接归还池中 -
pipeline同理，所有命令暂存在内存 buffer 中，直到exec才一次性发出；它不占用额外连接，但单次 pipeline 命令数不宜超过 500，否则可能触发 Redis 的client-output-buffer-limit限制 - ⚠️ 切勿跨协程复用
Redis实例（如把$redis存到全局变量或静态属性），协程上下文隔离失效会导致命令错乱或连接泄漏 - 推荐写法：在方法内通过 DI 获取
Redis实例（如$this->redis），或使用make(RedisFactory::class)->get()显式获取，确保每次都是干净协程上下文
为什么 DB::transaction() 有时不生效，或报 Connection is closed？
这不是 Bug，而是协程生命周期与连接池管理的耦合问题：
- Hyperf 的事务默认绑定当前协程获取的连接；如果事务内发生协程切换（如调用另一个 HTTP 请求、sleep、或 await 其他协程），该连接可能已被回收或复用，导致后续 SQL 报错
-
Connection is closed多见于长事务（>60 秒）——因为连接池默认max_idle_time=60.0，空闲超时后连接被主动关闭，但事务尚未提交 - 解决办法：对长事务，显式延长连接空闲时间（配置
max_idle_time至 > 事务预计耗时），或改用DB::connection()->beginTransaction()+ 手动commit()/rollback()控制粒度 - 更稳妥的做法：避免在事务内做非数据库操作（尤其是网络 IO），把事务范围缩到最小；必要时拆分为多个短事务 + 补偿逻辑
协程不是魔法，它只是把“等待 IO”的时间腾出来干别的事；但连接资源仍是有限的，且有明确生命周期。真正容易被忽略的，是事务边界与协程生命周期的隐式重叠 —— 这种问题在线上压测时才暴露，本地开发几乎看不出异常。
