codeigniter缓存需按类型精准管控：页面缓存依赖$this->output->cache()和application/cache/权限，数据库缓存必须手动cache_delete()防脏数据，高并发下必须切换redis替代file驱动。
CodeIgniter缓存机制优缺点全揭秘，不是泛泛而谈的理论堆砌，而是直击真实项目中页面加载卡顿、数据库查询暴增、缓存文件爆炸式增长等具体问题，用实测数据和可复现的操作路径说明哪些缓存能开、哪些必须关、哪些开了反而拖垮系统。
页面缓存：快得像静态页，但有个致命前提
第一步：在控制器方法任意位置插入 $this->output->cache(5);，其中 5 表示缓存 5 分钟。
第二步：确保 【application/cache 目录权限为 755 或 777，且 Web 服务器用户有写入权限】，否则缓存文件根本无法生成，页面始终走完整执行流程。
第三步：访问该页面一次，刷新后查看 application/cache/ 目录下是否生成了以 URI 的 MD5 值命名的文件——有则成功，无则检查权限或确认是否调用了 $this->load->view() 输出视图（仅 return view 内容不触发缓存）。
这一步操作起来很简单，直接把文件拖进去就行。但注意：缓存只对通过 $this->load->view() 渲染的完整响应生效，若控制器方法里用了 echo、json_encode() 或 return $this->response->setJSON() 等非视图输出方式，缓存完全无效。
数据库查询缓存：SELECT 能缓，INSERT 却永远绕不开
方法一：全局启用（推荐用于读多写少的后台报表页）
打开 application/config/database.php，将 'cache_on' => TRUE 设为 true，并指定 'cache_dir' => APPPATH.'cache/db/'，确保该目录可写。
方法二：按需开关（适合混合型页面）
在模型或控制器中，执行 SELECT 前调用 $this->db->cache_on();，执行完立即调用 $this->db->cache_off();，中间所有 SELECT 查询结果都会落盘。
方法三：精准清除（避免缓存脏数据）
当用户提交评论后，必须立刻清除对应页面的缓存：$this->db->cache_delete('blog', 'comments');——这里的 'blog' 和 'comments' 必须与控制器类名和方法名完全一致，大小写敏感，拼错一个字母缓存就永远不会更新。
缓存文件不会自动过期，【一旦开启，就必须在业务逻辑中主动调用 cache_delete 或 cache_delete_all，否则新数据永远不显示】。比如博客文章列表页缓存了 3 小时，期间新增 10 条评论，用户刷 100 次页面看到的仍是旧数据。
CI4 缓存处理器：File 是默认，Redis 才是高并发刚需
打开 app/Config/Cache.php，找到 public string $handler = 'file'; 这一行。
若当前是单机中小流量应用，保持 file 即可，缓存文件存于 WRITEPATH . 'cache/'，路径清晰、调试方便。
若已部署 Redis 服务且并发请求超过 500 QPS，必须改为：public string $handler = 'redis';，并配置 redis 数组中的 host、port、password 等参数——File 缓存在高并发下会产生大量磁盘 I/O 锁争用，响应时间可能从 20ms 暴涨至 800ms，而 Redis 可稳定在 5ms 内。
不要忽略 public int $ttl = 60; 这个值，它代表默认缓存秒数。CI4 的 TTL 是硬性过期，不像 CI3 那样依赖文件修改时间戳，改完立刻生效。
