webman性能问题需协同优化连接池、缓存设计与路由：redis须用webman/redis连接池（min=2, max=20），缓存key必须含业务域、参数签名（md5(json_encode)）和版本号，请求内需加临时缓存，fastroute路由要避免复杂正则、优先静态路由。
Webman连接池配置不当导致Redis连接数爆炸
直接在控制器里 new Redis() 或手动调用 redis_connect()，每个请求都会新建连接，Worker 进程常驻内存的特性反而会把连接数推到崩溃边缘——TIME_WAIT 堆积、Redis 拒绝新连接、Too many open files 报错都是典型信号。
必须用连接池管理，推荐 webman/redis 扩展：
- 安装：
composer require webman/redis - 配置
config/redis.php中的'pool' => ['min_connections' => 2, 'max_connections' => 20]，别设成 100+，实际压测发现 20 已覆盖 99% 场景 - 业务中统一走
Redis::get('key')，底层自动复用连接，不要自己存全局变量或在onWorkerStart里 new 实例 - 注意：PHP-FPM 下能凑合的写法，在 Webman 里就是定时炸弹
缓存Key设计不带版本号和上下文引发雪崩
写死 Cache::set('user_list', $data) 看似简单，但改了分页逻辑、加了新筛选条件、甚至只是切了测试环境，缓存就彻底失效或污染——更糟的是多个环境共用 Redis 时，user_list 可能被 QA 环境刷掉生产数据。
Key 必须包含三要素，缺一不可：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 业务域：
user:list明确作用范围 - 参数签名：用
md5(json_encode([$page, $size, $type]))，不用serialize()（PHP 版本升级会变格式） - 缓存版本：
:v2这种显式标记，改逻辑时只动版本号，旧 key 自然过期，比批量 del 安全可控 - 敏感字段如用户 ID 绝对不能裸拼进 key，防缓存探测攻击
单请求内重复查库没做请求级缓存
一个接口里多次调用 Db::table('users')->where('id', $uid)->first()，哪怕 Redis 缓存命中，同一次请求仍会查三次数据库——这不是缓存没用，是没用对地方。
Webman 的请求生命周期足够长，适合两级缓存：
- 第一级：请求内临时缓存，用
context()->get('cache')或静态变量，比如static $user_cache = []; - 第二级：Redis，供跨请求复用；但第一级必须存在，否则高并发下穿透压力仍在
- 注意：不要用
$_SESSION或全局数组模拟，Webman 是多进程模型，它们不共享
FastRoute路由未预编译或正则滥用拖慢匹配
Webman 默认用 FastRoute，但它不是“开箱即用就最快”。如果你在 route.php 里写一堆带复杂正则的动态路由，比如 GET /api/v1/posts/{id:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}}，每次请求都要跑完整正则引擎，QPS 上万时这部分开销会明显浮出水面。
优化重点在定义阶段：
- 静态路由优先于动态路由，
GET /health这种直接写死，不占匹配开销 - 动态参数约束尽量简单，
{id:\d+}比{id:.+}快得多 - 避免嵌套路由组里套正则，把
/api/v1/前缀提出来统一处理 - 确认
config/route.php中没开启调试模式下的实时重编译（生产环境必须关）
