phpredis 本身不占大量内存，真正耗内存的是 laravel 序列化缓存值、redis 连接重复实例化及未压缩大数据；优化关键在正确使用：确认启用 phpredis 而非 predis、禁用持久连接、对大值启用 zlib 压缩、避免全量模型缓存。
phpredis 本身不直接“占用”大量 PHP 内存，真正吃内存的是 Laravel 序列化后的缓存值 + Redis 连接对象的重复实例化 + 未压缩的大数据体。优化重点不在扩展本身，而在怎么用它。
确认你真在用 phpredis 而不是 predis
很多项目声称用了 phpredis，实际跑的是 predis（Composer 包）。这会导致序列化开销翻倍、连接管理更重、内存滞留更明显。
- 检查
config/database.php中'redis.client'是否设为'phpredis'，且环境变量REDIS_CLIENT=phpredis - 运行
php -m | grep redis确认 phpredis 扩展已加载（不是predis） - 执行
Cache::store('redis')->get('test')后，用memory_get_usage(true)对比 predis 场景，通常能省 1–3MB/请求
禁用 phpredis 的持久连接（persistent）
看似能复用连接，实则在 Laravel 的短生命周期请求中极易造成连接泄漏和内存堆积，尤其配合队列 worker 时。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在
config/database.php的 redis 配置里，删掉或显式设为'persistent' => false - 不要依赖
'prefix' => 'laravel_database_'来“隔离”，它只是键前缀，不影响连接对象生命周期 - 若用 Swoole 或 RoadRunner，才需谨慎评估
persistent；普通 FPM 下一律关掉
对缓存值启用 zlib 压缩（Laravel 7.x 兼容方案）
Laravel 7.x 不支持 config/cache.php 里直接配 'serializer' => 'zlib'，必须手动封装 Store。
- 新建
app/Cache/CompressedRedisStore.php，继承Illuminate\Cache\RedisStore - 重写
serialize()：仅当strlen($value) > 1024时调用gzcompress($value, 6)，否则直传 - 重写
unserialize()：先尝试gzuncompress()，失败则 fallback 到原值 - 在
config/cache.php的stores中注册该 store，并确保default指向它
避免 Eloquent 模型全量缓存
缓存 User::find(123) 返回的完整模型，等于把整个关系图谱、访问器、隐藏字段、元数据全塞进 Redis——单个模型常超 50KB，压缩后仍占 15KB+。
- 改用数组投影：
Cache::remember('user:123', 3600, fn() => User::find(123)->only(['id', 'name', 'email'])) - 禁用自动追加：
protected $appends = [];在模型中显式清空 - 别用
Cache::tags()缓存模型集合，标签本身会额外存储索引结构，大集合下索引体积可能超过数据本身
最容易被忽略的一点：Laravel 7.x 的 RedisStore 默认会对每个缓存值再套一层 serialize()，哪怕你存的是字符串。这意味着一个 10KB 的 JSON 字符串，最终在 Redis 中占 10.8KB —— 而启用 zlib 后可压到 3.2KB。这不是配置开关的问题，是必须动手改 Store 的硬门槛。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
