CodeIgniter 原生不支持 Redis：CI 3.x 需手动编写 Cache_redis.php 驱动并实现 save/get/delete/clean 方法，CI 4.x 虽内置但需手动配置 $redis 数组且 password 为空时须设为 null；键名避免特殊字符，注意序列化兼容性与 clean() 性能陷阱。
CodeIgniter 原生不支持 Redis，必须通过自定义驱动或第三方库接入；直接改 config/cache.php 选 redis 驱动会报错——因为 CI 3.x 默认没这玩意，CI 4.x 虽内置但依赖 ext-redis 且配置项命名和行为与直觉不符。
CI 3.x 中手动集成 Redis 驱动（最常用场景）
官方缓存类只认 file、apc、memcached 等内置驱动，Redis 需自己写一个 Redis 类并注册为缓存适配器。
- 把
application/libraries/Cache/drivers/Cache_redis.php文件建好，类名必须是CI_Cache_redis，继承CI_Driver - 核心方法
save()、get()、delete()、clean()必须实现，内部用$this->redis->set()这类调用（需提前在构造函数里实例化Redis扩展对象） - 在
config/cache.php中设$config['adapter'] = 'redis'，同时确保$config['redis_server']等自定义配置已存在 - 别漏掉
autoload['libraries'] = ['cache']，否则$this->cache->redis会报Undefined property
CI 4.x 使用内置 Redis 缓存（注意配置陷阱）
CI 4.3+ 内置 redis 缓存驱动，但默认配置文件里没有对应项，且键名不叫 redis 而是 redis ——看着一样，实际要手动补全整个配置块。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在
app/Config/Cache.php中添加public $redis = [...]配置段，字段包括host、password、port、timeout、database - 驱动启用靠
$handler = 'redis'，不是redis_cache或rediscache，写错就回退到file - 若 Redis 服务启用了密码但
password设为空字符串（''），CI 4 会静默失败——必须设为null才跳过认证 -
save($key, $value, $ttl)的$ttl单位是秒，但若传0表示“永不过期”，不是“用默认 TTL”——这点和 Memcached 不同
缓存键设计与序列化问题（高频翻车点）
CI 的缓存层默认对值做 serialize()，而 Redis 原生更倾向字符串；当存数组或对象时，CI 3.x 的自定义 Redis 驱动若没处理好反序列化，get() 可能返回 false 或乱码。
- CI 3.x 自定义驱动中，
get()返回前务必用unserialize()，且要加is_string()和!empty()判断，否则遇到空值或非序列化字符串直接崩 - CI 4.x 默认用
igbinary（如果扩展存在）或serialize，但你无法控制——若业务中混用 PHP 原生redis->set()写入数据，CI 读取时大概率失败 - 避免在键名中使用
:、{、}等特殊字符，CI 缓存类不做转义，Redis 虽允许，但和其他系统对接时容易冲突 - 高并发下慎用
clean()，它在 CI 3.x 是遍历 keys + delete，在大数据量时阻塞严重；CI 4.x 改用SCAN，但默认 limit 仅 100，得自己扩参
真正麻烦的不是连上 Redis，而是缓存失效时机、键冲突、序列化兼容性这些看不见的链路。尤其当 CI 和 Laravel 服务共用一个 Redis 实例时，serialize vs json_encode、前缀约定、TTL 策略稍有不一致，查 bug 就得翻日志+抓包+手写 debug 脚本。
