OPcache 是 PHP 字节码缓存，仅加速脚本执行；Redis 是通用内存数据库，用于缓存业务数据。二者定位不同，不可互相替代：OPcache 不支持存业务数据、跨请求共享或过期机制，Redis 则专为此设计。
OPcache 是什么，为什么它不能替代 Redis
OPcache 是 PHP 自带的字节码缓存，只加速 PHP 脚本的执行——它把 php.ini 里编译后的 opcode 缓存在共享内存里，跳过重复解析和编译。但它不存业务数据，也不跨请求共享变量，更不支持过期、序列化或复杂查询。
Redis 是独立进程的内存数据库，用来缓存你手动 set() 的任意数据（比如用户信息、API 响应、计数器），支持 TTL、原子操作、发布订阅等。两者定位完全不同：OPcache 加速“PHP 本身”，Redis 加速“你的代码逻辑”。
常见误用：
- 把 OPcache 当成通用缓存，试图用它存数组或对象 → 不支持
- 关闭 OPcache 却狂堆 Redis → 脚本解析开销飙升，尤其高并发时 file_get_contents 或 require 大量文件会明显卡顿
- 只配 OPcache 不配 Redis → 动态内容（如用户 session、商品库存）仍反复查 DB
启用 OPcache 的最小安全配置
默认 PHP（8.0+）已编译 OPcache，但多数 Docker 镜像或一键包默认关闭。关键不是“开”，而是“开对”：
-
opcache.enable=1必须设为1（CLI 模式下默认为0，Web SAPI 才生效） -
opcache.memory_consumption=128—— 小项目 64MB 够用，大项目建议 128–256MB；设太小会导致频繁淘汰，opcache_get_status()['opcache_statistics']['oom_count']> 0 就是内存溢出信号 -
opcache.max_accelerated_files=20000—— 必须 ≥ 项目中 PHP 文件总数（可用find /path/to/app -name "*.php" | wc -l估算），否则部分文件不被缓存 -
opcache.revalidate_freq=2—— 开发环境可设为0（每次请求都校验文件修改时间），生产环境建议 2–60 秒，避免热更新后旧代码残留 - 禁用
opcache.validate_timestamps=0在生产环境——否则改了代码不重启 PHP-FPM 就不会生效
验证是否生效：php -m | grep opcache 看是否列出，再访问 phpinfo() 页面搜索 “OPcache” 查状态。
立即学习“PHP免费学习笔记（深入）”；
Redis 缓存 PHP 数据的典型写法与避坑点
别直接用 ext-redis 存数组或对象——它默认不序列化，存进去的是乱码或报错 RedisException: Cannot serialize。正确做法：
- 用
serialize()+unserialize()（兼容性好，但性能略低）：$redis->set('user:123', serialize($user));$user = unserialize($redis->get('user:123')); - 用
json_encode()+json_decode()（推荐）：$redis->setex('user:123', 3600, json_encode($user));$user = json_decode($redis->get('user:123'), true);—— 注意第二个参数true，否则返回stdClass - 避免用
setnx()实现锁却不设 TTL → 死锁风险。改用set('lock:key', '1', ['nx', 'ex' => 10]) - 批量读用
mget(['key1','key2'])，别循环调get()；批量写优先用pipeline()减少网络往返
注意：redis.conf 中 maxmemory 和 maxmemory-policy 必须明确设置，否则内存爆掉后 Redis 会拒绝写入（错误：OOM command not allowed when used memory > 'maxmemory'）。
OPcache 和 Redis 共存时的真实瓶颈在哪
很多人配完两者还慢，问题往往不在缓存本身，而在连接和生命周期管理：
- 每次请求都 new
Redis实例 → TCP 连接开销大。改用连接池或静态复用（如Redis::connect()后复用句柄） - OPcache 的
opcache.file_cache（磁盘缓存）开启后反而拖慢 NFS 或容器卷 → 生产环境建议关掉，专注共享内存 - Redis 存了大量小 key（如
cache:user:123:profile,cache:user:123:settings）→ key 数量爆炸，keys *类命令卡死。改用 Hash 结构：hset user:123 profile $json_profile settings $json_settings - OPcache 缓存命中率长期 include $file）或 eval —— 这类代码无法被 OPcache 缓存
最常被忽略的一点：PHP-FPM 的 pm.max_children 设置不合理，导致并发上来后，即使缓存全命中，也因 worker 耗尽而排队等待，看起来像“缓存没起作用”。
