phpredis原生扩展性能最优，需直连测试：启用pconnect复用连接、禁用OPcache CLI干扰、控制单key≤512字节、避免Laravel封装层，方能真实反映其高吞吐低延迟特性。
直接测 phpredis 并发性能，别用 Cache::store('redis') 包裹层——它会掩盖底层连接行为，测出来的是 Laravel 缓存抽象的性能，不是 phpredis 本身。
用 phpredis 原生扩展直连测压
你得绕过 Laravel 的 Cache 和 Redis facade，直接调用 Predis\Client 或 Redis 扩展原生类（推荐后者，因 phpredis 是 C 扩展，更贴近真实并发表现）。否则测的是框架封装、序列化、键前缀、驱动路由等中间逻辑。
- 确认已启用
phpredis：运行php -m | grep redis，输出含redis且无报错 - 在
php artisan tinker中手动实例化：$redis = new Redis(); $redis->connect('127.0.0.1', 6379, 2.0);（注意设$timeout防卡死） - 写入测试用
$redis->set("key_{$i}", str_repeat('x', 128), 3600)，别用setex—— 它在旧版 phpredis 中非原子，可能干扰结果 - 读取用
$redis->get("key_{$i}")，避免exists + get组合，那会翻倍网络往返
并发场景必须启用持久连接
默认 connect() 每次新建 TCP 连接，高并发下三次握手+TIME_WAIT 会迅速打满本地端口或触发连接拒绝。不加 pconnect() 测出来的延迟全是建连开销，不是 Redis 处理能力。
- 改用
$redis->pconnect('127.0.0.1', 6379, 2.0)，注意它不能跨 FPM worker 进程复用，但在单个 CLI 进程内可复用连接 - 在
config/database.php的redis.default配置中加'persistent' => true，并确保.env中REDIS_CLIENT=phpredis - 测压前用
redis-cli client list | wc -l观察连接数是否稳定（比如 200 并发只维持 20–30 个连接，说明池化生效）
避开常见干扰项
很多“测出 phpredis 很慢”的报告，实际是被 PHP 自身机制拖累，而非 Redis 或扩展问题。
- 禁用 OPcache 的 CLI 模式干扰：临时设
opcache.enable_cli=0，否则tinker每次执行都可能触发字节码重编译 - 不要在 Web 环境测：FPM 子进程生命周期短，
pconnect失效；且日志、调试器、中间件全在抢 CPU - 避免大值传输：单 key 超过 10KB 时，
phpredis序列化/内存拷贝开销陡增，建议统一用 128–512 字节模拟典型业务数据 - 检查 Redis 服务端配置：确认
maxmemory未触发 LRU 驱逐，latency-monitor-threshold设为 0 关闭延迟监控（它本身有开销）
真实业务中要注意的边界
即使 phpredis 单连接吞吐很高，Laravel 项目里真正卡点往往不在它身上。
- 连接池是假象：FPM 下每个 worker 进程持有一个
pconnect连接，200 个并发请求若分到 20 个 worker，实际只有 20 条连接在跑——别指望它能撑住 1000+ 并发而不扩容 Redis - 阻塞操作仍存在：比如
$redis->brpop()用在队列消费时，会阻塞整个 PHP 进程，此时并发提升反而降低吞吐 - 序列化成本不可忽略：默认
serialize()对数组/对象体积放大 3 倍以上，换成igbinary（需扩展支持）可降 60% 内存和网络负载
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
