Laravel的缓存系统默认支持多种驱动，其中Redis是最常用的生产环境选择。不过大多数教程只演示了简单的字符串缓存用法，即把一个数组或对象整体序列化后存入一个key。这种做法在数据结构简单时没有问题，但当缓存的是一个包含大量字段的对象，且业务只需要更新其中一两个字段时，整体读写就会带来不必要的序列化开销。Redis的Hash结构正好解决这个问题，它允许在一个key下面按字段独立存取数据，实现细粒度的缓存控制。
Redis Hash的底层结构与适用场景
Redis Hash本质上是一个键值对集合，一个Hash key内部可以包含多个field-value对。在Redis内部实现中，当Hash的字段数量较少且每个值较小时，采用listpack（旧版本是ziplist）这种紧凑的连续内存结构存储；当字段数量或单个值超过阈值后，会转换为标准的哈希表结构。这种设计使得小型Hash在内存占用上非常友好。
理解这个特性对缓存设计很重要。假设我们缓存一个用户信息对象，包含用户名、头像、邮箱、签名等字段。如果用字符串结构存储，每次更新签名都要把整个对象读出来、反序列化、修改、再序列化写回。而使用Hash结构，只需要执行一次HSET user:1001 signature "新签名"，其他字段完全不受影响。这种字段级别的读写能力，就是Hash缓存的核心价值。
典型的适用场景包括：用户会话数据、商品详情的多语言字段、需要部分更新的配置信息、计数器与属性混合存储的对象等。反过来说，如果数据总是整体读取、整体写入，且体积很小，那么字符串结构反而更简单直接。
在Laravel中使用Redis门面直接操作Hash
Laravel提供了Illuminate\Support\Facades\Redis门面，可以直接调用所有Redis原生命令，包括Hash系列命令。这是最灵活的方式，适合需要精细控制Hash结构的场景。首先确认config/database.php中已经配置了redis连接，然后在.env中设置CACHE_DRIVER或直接使用Redis门面即可。
<?php
use Illuminate\Support\Facades\Redis;
// 写入单个字段
Redis::hSet('user:1001', 'name', '张三');
Redis::hSet('user:1001', 'email', 'zhangsan@ipipp.com');
// 批量写入多个字段
Redis::hMSet('user:1001', [
'avatar' => 'https://ipipp.com/avatar/1001.png',
'sign' => '热爱编程',
]);
// 读取单个字段
$name = Redis::hGet('user:1001', 'name');
// 读取多个字段
$info = Redis::hMGet('user:1001', ['name', 'email']);
// 读取全部字段
$all = Redis::hGetAll('user:1001');
// 判断字段是否存在
if (Redis::hExists('user:1001', 'phone') === false) {
Redis::hSet('user:1001', 'phone', '13800000000');
}
// 数值字段的原子自增，常用于计数器
Redis::hIncrBy('user:1001', 'login_count', 1);
// 删除单个字段而不是整个key
Redis::hDel('user:1001', 'sign');
// 设置过期时间，作用于整个Hash
Redis::expire('user:1001', 3600);
需要注意的是，Hash的过期时间是作用于整个key的，无法对单个field单独设置TTL。Redis 7.4虽然引入了field级别的过期支持，但需要确认你的Redis版本和客户端扩展是否支持。在Laravel中，建议在写入Hash后统一调用expire设置整体过期时间，并配合定时任务或读取时的兜底逻辑重建缓存。
另外要留意序列化问题。通过Redis门面写入的值会经过phpredis或predis扩展的处理，默认只存字符串。如果某个字段的值是数组，需要自己调用json_encode或serialize，读取后再手动解码，这一点和Cache门面的自动序列化行为不同。
通过Cache门面配合自定义Store使用Hash
如果希望保持Laravel缓存API的统一风格，也就是继续使用Cache::get、Cache::put这些方法，同时底层换成Hash存储，可以自定义一个Cache Store。Laravel的缓存系统是高度可扩展的，只需要实现Illuminate\Contracts\Cache\Store接口并注册即可。
<?php
namespace App\Cache;
use Illuminate\Contracts\Cache\Store;
class RedisHashStore implements Store
{
public function get($key)
{
$data = \Illuminate\Support\Facades\Redis::hGetAll($this->prefix($key));
return empty($data) ? null : $data;
}
public function put($key, $value, $seconds)
{
if (!is_array($value)) {
$value = ['__value__' => serialize($value)];
}
\Illuminate\Support\Facades\Redis::hMSet($this->prefix($key), $value);
\Illuminate\Support\Facades\Redis::expire($this->prefix($key), (int) $seconds);
return true;
}
public function increment($key, $value = 1)
{
return \Illuminate\Support\Facades\Redis::hIncrBy($this->prefix($key), 'counter', $value);
}
public function forget($key)
{
return (bool) \Illuminate\Support\Facades\Redis::del($this->prefix($key));
}
// 简化的前缀处理
protected function prefix($key)
{
return 'hashcache:' . $key;
}
// 接口中的其他方法按类似思路实现即可
}注册自定义Store的思路是继承CacheManager或者利用Cache::extend方法在服务提供者中挂载。这种方式的好处是业务代码完全无感知，切换缓存策略时不需要改动任何调用处的代码。缺点是需要补全接口的全部方法实现，例如many、putMany、flush等，工作量比直接使用Redis门面要大一些。
Hash缓存与字符串缓存的对比及实践建议
两种方案各有取舍。字符串缓存的优点是Laravel原生支持最好，序列化和反序列化完全自动化，代码量最少；缺点是任何局部修改都要整体读写，对象体积大时网络传输和CPU开销都会放大。Hash缓存的优点是字段级读写、支持原子计数器、网络传输量小；缺点是无法对字段单独设置过期时间，且通过门面操作时需要自己处理序列化。
| 对比维度 | 字符串缓存 | Hash缓存 |
|---|---|---|
| 读写粒度 | 整个key | 单个field |
| 序列化 | 框架自动处理 | 需手动处理数组字段 |
| 过期控制 | 按key设置TTL | 按key设置TTL，字段级TTL需高版本Redis |
| 原子计数 | INCR整体数值 | HINCRBY按字段计数 |
| 适用场景 | 整体读写的简单数据 | 多字段对象、需局部更新 |
实践中有几点经验值得注意。第一，Hash的单个字段值不宜过大，如果某个字段是几兆字节的大JSON，Hash结构反而会失去优势，此时应该把这个大字段拆成独立的字符串key。第二，注意Redis配置中的hash-max-listpack-entries和hash-max-listpack-value参数，字段数量很多的Hash会退化为哈希表结构，内存占用会上升，这是正常现象但要有心理预期。第三，缓存key的命名建议带上业务前缀和主键，例如user:1001、goods:2001:detail，方便排查问题和批量清理。
最后提醒一点，使用Redis门面时建议显式指定连接，例如Redis::connection('cache')，把缓存操作和队列操作隔离到不同的Redis实例或逻辑库中，避免大量缓存读写影响队列的正常消费。合理利用Hash结构的细粒度特性，配合统一的key命名规范和兜底重建逻辑，就能构建出既高效又易于维护的缓存层。
Laravel Redis缓存Redis Hash缓存存储修改时间：2026-09-01 11:44:37