CodeIgniter性能优化需按项目类型针对性实施：电商类启用持久连接、页面缓存和Session条数限制；后台系统关闭调试、分析慢SQL、避免N+1查询；API服务精简加载、合理过滤输入并启用OPcache。
CodeIgniter本身轻量、启动快，但真实项目性能不只取决于框架，更取决于来源项目结构、数据库交互方式、缓存策略和请求生命周期管理。没有统一“基准值”，但可通过几类典型来源项目横向对比，快速定位瓶颈并针对性优化。
电商类项目（如美丽说源码）：高并发读+会话依赖强
这类项目通常商品页、搜索页访问密集，用户行为链路长（浏览→加购→下单→支付），对Session和数据库查询效率敏感。
- 典型瓶颈：未启用持久连接（
pconnect => FALSE）时，每请求新建MySQL连接，QPS超200即明显延迟 - 关键优化点：
✓ 将pconnect设为TRUE，配合MySQL的wait_timeout调至300秒以上
✓ 商品列表页强制启用output_cache（如5分钟），避免重复查库存与分类
✓ 用户浏览历史用Session记录，但限制条数（如最多10条），避免session文件/DB膨胀
后台管理系统：低频但逻辑复杂、ORM调用多
权限校验、日志记录、多表关联更新频繁，常因模型层过度封装或N+1查询拖慢响应。
- 典型瓶颈：Base Model中
get_by()未加索引字段条件，或update_by()未限定WHERE范围导致全表扫描 - 关键优化点：
✓ 在application/config/database.php开启db_debug = FALSE（生产环境必须）
✓ 使用$this->db->last_query()抓取慢SQL，结合EXPLAIN分析执行计划
✓ 避免在循环中调用$model->get()，改用get_many_by()批量拉取
API服务类项目：无视图、纯JSON输出、高吞吐要求
常对接小程序或APP，接口响应时间需稳定在100ms内，对自动加载、路由解析、输入过滤开销更敏感。
- 典型瓶颈：大量使用
$this->input->post()或->get()且未指定NULL默认值，触发冗余XSS过滤 - 关键优化点：
✓ 关闭非必要库（如form_validation、upload）仅在需要控制器中load
✓ 输入参数用$this->input->get('id', TRUE)中第二个参数TRUE启用过滤，但FALSE可跳过（若已知可信来源）
✓ 启用PHP OPcache + CodeIgniter的config/autoload.php预加载核心类，减少运行时查找
Profiler不是万能的，但它是第一双眼睛
开发阶段打开$this->output->enable_profiler(TRUE)，重点关注三块：
- “Database Queries”：超过5条查询/页面要警惕，>10条基本存在N+1问题
-
“Memory Usage”：单请求超2MB说明有大对象未释放（如未
unset($huge_array)） - “Session Data”：显示当前session写入大小，>4KB易触发文件锁或DB写阻塞
真正压测时，建议用ab或wrk对关键接口实测，例如：wrk -t4 -c100 -d30s http://yoursite.com/api/products
观察平均延迟、错误率与吞吐变化，再比对Profiler数据交叉验证。
