CodeIgniter性能调优关键在理清请求链路、控制资源开销、避免隐性瓶颈：入口index.php启动快但需精简autoload；数据库启用pconnect并调优MySQL参数；缓存分层落地，禁用低效文件缓存；Profiler仅开发使用且聚焦重复查询、慢查询与控制器耗时异常。
CodeIgniter项目性能调优，关键不在堆功能，而在理清请求链路、控制资源开销、避免隐性瓶颈。实际项目中，慢往往不是框架本身的问题，而是配置失当、连接滥用或缓存缺失导致的。
入口与加载流程决定响应起点
每个请求都从 index.php 开始，它定义了 APPPATH、BASEPATH 等路径常量，并引入 system/core/CodeIgniter.php。这个文件按顺序加载核心类（Router、Input、Loader、Config 等），其中 Router 解析 URL 路由，Loader 加载控制器——整个过程无自动扫描，所以启动快。但若在 application/config/autoload.php 中过度预加载库（比如把 image_lib、email 等非必需项全设为自动加载），会拖慢每请求的初始化时间。
- 只 autoload 真正全局需要的项，如 session、database（若全站依赖）
- 控制器内按需
$this->load->library('xxx')，而非“以防万一”全加 - 检查
system/core/CodeIgniter.php中的类加载顺序，确认无冗余实例化
数据库连接配置是高并发下的第一道闸口
默认 pconnect = FALSE 意味着每次请求新建连接、用完即关，这对中小流量尚可，但在 QPS > 50 的场景下极易触发 MySQL 的 max_connections 限制，出现 “Too many connections” 或 “MySQL server has gone away”。真实项目中应启用持久连接并配套调优：
- 将
'pconnect' => TRUE写入application/config/database.php - 同步调整 MySQL 的
wait_timeout（建议设为 28800 秒）和max_allowed_packet - 字符集必须统一为
'char_set' => 'utf8mb4'和'dbcollat' => 'utf8mb4_unicode_ci'，否则查询时隐式转换拖慢执行 - 避免多组配置共用同一数据库账号却未隔离权限，防止某模块误操作影响全局
缓存策略要分层落地，不只靠开关
CodeIgniter 提供页面级、查询级、片段级三种缓存能力，但仅开启 $config['cache_enabled'] = TRUE 不等于性能提升——缓存内容若过期不及时、键名无区分度、或命中率低，反而增加 I/O 开销。
- 数据库查询缓存只对
get()类只读查询生效，且要求$config['query_cache_enabled'] = TRUE+cache_on在 DB 配置中设为 TRUE - 用户登录态等动态数据，推荐用 Redis 或 Memcached 替代文件缓存，避免磁盘锁争用
- 视图片段缓存（
$this->load->view('xxx', $data, TRUE)+ file write）慎用于含用户个性化内容的区块 - 静态资源（CSS/JS/图片）交由 Nginx 的
expires指令托管，不走 PHP 层
Profiler 是诊断而非装饰，要用在刀刃上
$this->output->enable_profiler(TRUE) 能实时显示查询次数、执行时间、内存占用等，但它本身有 10%~15% 性能损耗。上线前务必关闭，开发中则聚焦三类异常信号：
- 单页出现 >5 次重复查询（典型如循环中调
$this->db->get_where()） - Query time > 200ms 且无索引提示（配合
EXPLAIN分析） - “Loading Time: X.XX sec” 中 “Controller Execution Time” 占比过高，说明逻辑未下沉到模型或存在阻塞操作（如未异步的 curl 请求）
