memcached 在 workerman 中不推荐直接使用，因其阻塞式设计与 workerman 多进程常驻模型冲突，易导致连接打爆、延迟飙升、数据不一致；官方推荐使用带连接池的 webman/redis。
Memcached 在 Workerman 中不推荐直接对接，尤其在高频读取场景下——它会立刻暴露连接管理缺陷，导致延迟飙升、连接打爆、数据不一致。
这不是配置问题，而是模型冲突：Workerman 是常驻内存、多进程（或协程）模型，而原生 Memcached PHP 扩展是阻塞式、无连接池、无状态复用设计的。每次 new Memcached() 都新建 TCP 连接，Worker 进程数 × 并发量 = 瞬间压垮 memcached 服务端。
为什么 new Memcached() 在 Workerman 里必出问题
高频读取场景下，你看到的现象通常是：
-
P99 延迟从 1ms 跳到 120ms+（连接争抢 + TCP 握手开销） -
memcached进程 CPU 100%，netstat -an | grep :11211 | wc -l显示连接数远超-c 1024限制 - 不同 Worker 进程缓存同一 key 却返回不同值（因各自连接未同步，
add()和get()语义错乱） - 进程重启后本地
Memcached实例丢失，但无兜底重连逻辑，后续请求直接报Memcached::get(): sendmsg: Broken pipe
根本原因：PHP 的 Memcached 扩展没有 onWorkerStart 生命周期感知，也不支持 Swoole/Workerman 要求的连接池、心跳检测、熔断降级。
Webman/Workerman 官方只认 Redis 连接池
Webman 生态中 webman/redis 是唯一深度集成、带连接池管理的缓存客户端；Workerman 社区实践也已收敛到 Redis 方案。这不是“偏好”，而是架构适配结果：
一款AI工具，主要用于自动分析崩溃并修复错误。监控 Cloudflare D1 崩溃报告，进行去重和 Codex 5.3 High 分析，生成修复并创建...，适合需要提升相关任务效率的用户。
-
webman/redis默认启用连接池（可配min_connections=5,max_connections=20），连接自动复用、超时自动重建 -
SETNX + GETSET组合能防缓存穿透，INCR可直接做限流计数，PERSIST支持精准过期重置——Memcached的add/cas在高并发下极易失败 - 压测实测：2000 QPS 下，
webman/redis（池大小 15）平均延迟0.8ms；同等负载下硬上Memcached（new模式）P99 延迟突破120ms
别被“Memcached 更轻更快”的旧认知带偏——那是针对 FPM 场景的结论。Workerman 的长连接模型下，Redis 的连接池收益远大于 Memcached 的单连接裸奔。
真要强上 Memcached？必须自己实现连接池
如果你有历史依赖或特殊协议要求（比如已有 Memcached-only 的中间件），唯一可行路径是自研连接池，且必须满足：
- 连接预热：在
onWorkerStart中提前建立并验证 N 个连接，存入静态数组或Swoole\Coroutine\Channel - 租借/归还机制：每次读取前
pop一个连接，操作完push回去；超时未归还则强制销毁 - 心跳保活：起独立协程每 30 秒对每个连接发
stats，失败则标记为 dead 并重建 - 无全局变量：不能把
$memcached实例挂到Worker::$memcached，否则多进程间共享会导致Segmentation fault
这相当于重写一个轻量版 webman/redis，但社区无维护、无测试覆盖、无熔断能力。上线后第一个雪崩点大概率出在这里。
高频读取场景下，缓存层的稳定性比“省几毫秒”重要得多。webman/redis 不是妥协方案，而是 Workerman 架构下的必然选择。真正容易被忽略的点是：连接池大小不是越大越好——设成 50 反而增加调度开销；建议从 10~20 起步，配合 ab 或 wrk 压测 P99 延迟再微调。
