file适用于开发及小流量站点，无需依赖；redis适合集群环境、需精确TTL和原子操作的场景；memcached轻量快速但需配置backupHandler防雪崩。
怎么选缓存驱动：file、redis、memcached 各自适用场景
CodeIgniter 的缓存驱动不是“越高级越好”，而是看你的部署环境和实际瓶颈。默认 file 驱动最稳妥，但并发高时 I/O 成为瓶颈；redis 和 memcached 适合读多写少、需要共享缓存的集群环境，但前提是服务器已装好对应服务且 PHP 扩展启用。
-
file：开发/小流量站首选，无需额外依赖，缓存文件存在WRITEPATH . 'cache/'（即app/writable/cache/），但注意该目录必须可写且不能被 Web 直接访问 -
redis：支持 TTL 精确控制、原子操作、复杂数据结构，适合做会话缓存或需主动失效的业务键（如user_profile_123）；需确认Redis扩展已加载，且配置中$handler = 'redis'后要配好host/port/database -
memcached：轻量、快，但不支持持久化和复杂命令；若用它，记得设backupHandler = 'file'，避免 memcached 崩溃后全站缓存雪崩
为什么改了 $handler 还是走 file 缓存？检查这三处
缓存驱动切换失败，90% 是因为配置没生效或被覆盖。CodeIgniter4 的缓存配置分散在多个地方，容易漏掉关键项。
- 确认修改的是
app/Config/Cache.php中的$handler，不是旧版的application/config/cache.php（CI4 已废弃该路径） - 检查
$backupHandler是否设为'dummy'—— 如果主驱动初始化失败，CI4 会静默降级到dummy（即不缓存），不会报错，导致你以为“配置生效了”其实压根没存 - 运行
php spark cache:info（CI4 内置命令）查看当前实际加载的驱动和状态；若显示handler: file，说明配置未重载，尝试删掉writable/cache和writable/debugbar后重启
$this->cache->save() 失败却不报错？这是设计，不是 bug
CI4 的缓存驱动接口默认静默失败（fail-silently），尤其当 redis 连接超时或磁盘满时，save() 返回 false 但不抛异常 —— 这是为了避免缓存故障拖垮主业务逻辑，但开发者容易误以为“写成功了”。
- 务必检查返回值：
if (!$this->cache->save('key', $data, 300)) { log_message('error', 'Cache write failed'); } - 生产环境建议搭配
backupHandler：比如主用redis，备选file，这样即使 Redis 挂了，还能降级缓存到本地文件，不至于全量击穿 - 不要在
save()后立刻get()验证——某些驱动（如apcu）在 CLI 模式下无法跨进程读取，会导致测试误判
清理缓存时，$this->cache->clean() 到底清什么？
clean() 清的是当前配置的 $handler 下的所有缓存项，不是整个服务器、也不是所有驱动。很多人误以为它能“一键清空所有缓存”，结果线上 Redis 被清空，其他项目一起挂掉。
- 只清当前驱动：如果
$handler = 'redis'，clean()就是执行FLUSHDB，仅清当前 Redisdatabase；如果$handler = 'file'，就遍历删除writable/cache/下匹配前缀的文件 - 想清指定键？用
$this->cache->delete('key_name')，比clean()安全得多，也更精准 - 开发时别依赖
clean()自动刷新——它不触发钩子、不清理 OPcache、也不影响浏览器缓存，前端可能还在读旧 JS/CSS，得手动加版本号或硬刷新
$this->output->cache()，数据库查询用 $this->db->cache_on()，业务数据才轮到 $this->cache->save()。混用或跳过某一层，反而会让缓存变成性能黑洞。 
