CodeIgniter内存优化需从服务实例共享、自动加载精简和缓存驱动升级三方面入手：用Services管理共享实例避免重复构造；删减autoload中未使用的类映射，按需加载库与助手；将file缓存切换为Redis并清理旧缓存。
CodeIgniter 的内存占用问题，根源往往不在框架本身，而在类加载方式、实例生命周期和缓存策略上。直接调高 memory_limit 是临时止痛药，真正有效的优化要从服务实例共享、自动加载精简和缓存驱动升级三处下手。
用 Services 管理共享实例，避免重复构造
每次 new 一个库类，就多一份对象内存；尤其像日志处理器、HTTP 客户端、数据校验器这类通用工具类，在多个控制器里反复实例化会快速推高峰值内存。
- 把你的功能类（比如
App\Libraries\JwtHelper）改造成无状态或轻初始化的类 - 在
app/Config/Services.php中添加静态方法，显式声明为共享实例：public static function jwtHelper($getShared = true)<br>{<br> if ($getShared)<br> {<br> return static::getSharedInstance('jwtHelper');<br> }<br><br> return new \App\Libraries\JwtHelper();<br>} - 控制器中统一用
service('jwtHelper')获取——无论调多少次，返回的都是同一个对象 - 注意：不要在构造函数里做 heavy 初始化（如读大文件、建长连接），应延迟到首次调用方法时
砍掉 autoload 里的“默认全家桶”
很多项目在 app/Config/Autoload.php 里把 database、session、email 全塞进 $psr4 或 $libraries，结果每个请求都强制加载，哪怕这个请求只查个静态页。
- 检查
$psr4数组，删掉未实际使用的第三方包命名空间映射（比如你没用 Guzzle，就别留'GuzzleHttp' => SYSTEMPATH . 'ThirdParty/Guzzle/src/'） -
$libraries和$helpers保持为空数组，改用按需加载：$this->load->library('form_validation')只在需要表单验证的控制器里调 - 若某些 helper（如
url、html）高频使用，再加进$helpers，但别贪多 - CI4 中可配合 Composer 的 classmap 优化：部署时运行
composer dump-autoload --optimize，减少自动加载搜索开销
换掉 file 缓存驱动，Redis 才是生产环境标配
CI4 默认的 file 缓存看着省事，但每写一次缓存都要 fopen/fwrite/fclose，高并发下磁盘 I/O 成瓶颈，且缓存键冲突、权限错误、目录爆满等问题频发，反而增加内存压力（比如因缓存失败反复重建数据）。
- 确认 PHP 已启用
redis扩展：php -m | grep redis - 在
.env中设CACHE_HANDLER=redis，并配置连接参数：CACHE_HANDLER=redis<br>REDIS_HOST=localhost<br>REDIS_PASSWORD=<br>REDIS_PORT=6379<br>REDIS_TIMEOUT=0
- 在
app/Config/Cache.php中确保$handler = 'redis'，并检查$redis配置块是否匹配 - 缓存大数组或对象前先
serialize()或转成 JSON；Redis 原生不支持 PHP 对象，硬存会导致反序列化失败
最容易被忽略的是：服务共享和缓存驱动切换后，必须清理旧缓存目录（rm -rf writable/cache/）并重启 OPcache（如果开了）。残留的 file 缓存文件可能被误读，导致 Unserialize error 或无限循环重建，那才是真·内存泄漏。
