答案：ThinkPHP内存溢出需先定位是“单次撑爆”还是“缓慢累积”，再通过memory_get_peak_usage打点排查热点，禁用debug、改分页/批量查询、切Redis缓存、导出任务移至队列，并调优PHP-FPM与OPcache。
遇到 ThinkPHP 内存溢出或响应慢，别急着调大 memory_limit 或重启服务。真正的问题往往藏在运行逻辑和默认配置的叠加效应里——尤其是开发环境开着 debug、查全量数据、用文件 Session、没切 Redis、循环查库这些“看起来正常”的操作，在高并发或大数据量下会迅速放大成雪崩点。
先判断是“单次撑爆”还是“慢慢吃光”
看报错信息里的线索：
- 有明确文件和行号（如
in /app/controller/User.php on line 45），大概率是某次操作瞬间申请超限，比如json_decode($huge_json)、file_get_contents()读大文件、或Db::table('log')->select()拉了10万条数据 - 没位置信息，或堆栈指向
vendor/thinkphp/...内部（如 Template.php、Collection.php），说明内存早被前序代码悄悄占满，最后一步只是压垮骆驼的稻草 - CLI 命令报错但 Web 请求没事？重点查队列消费、导出脚本这类长期运行任务，它们常被忽略内存限制
快速定位内存热点的三步法
不用 Xdebug（它自己就吃内存），加三行 memory_get_peak_usage(true) 就能圈出问题区段：
- 控制器开头打点：
echo 'start: ' . memory_get_peak_usage(true) . "\n"; - 数据库查询后打点：
echo 'after db: ' . memory_get_peak_usage(true) . "\n"; - 模板渲染前打点：
echo 'before render: ' . memory_get_peak_usage(true) . "\n";
对比数值跳变。比如从 6MB 跳到 280MB，那中间那段就是重点排查对象——可能是没分页的 select()，也可能是嵌套 {volist} 导致模板重复解析。
立即学习“PHP免费学习笔记（深入）”；
高频踩坑点与对应动作
以下这些不是“可能有问题”，而是生产环境已验证的内存杀手：
-
查全量数据：禁用
Db::table('user')->select()，改用where('id', '>', $lastId)->limit(500)->select()游标分页，排序字段必须有索引 -
循环查库：把
foreach ($ids as $id) { Db::find($id); }改成Db::whereIn('id', $ids)->select() -
文件驱动缓存/Session：立刻切 Redis，否则所有请求排队等同一个 cache 文件锁；配置中确认
Cache::store('redis')而非Cache::get()（后者走默认 file） -
调试模式开着：生产环境必须设
app_debug = false，关掉 trace 日志、模板编译缓存自动更新、SQL 日志记录 - 导出类任务还在 Web 请求里跑：登录日志、消息通知、Excel 导出全部丢进队列，前端轮询状态，后端用 CLI 独立进程处理
别忽略底层支撑配置
框架层优化再好，PHP 运行层不匹配也会白搭：
- FPM 子进程数别硬塞 200，按 4核8G 服务器算，
pm.max_children = 64更稳妥，每 worker 控制在 20–30MB 内 - 开 OPcache：
opcache.enable=1、opcache.memory_consumption=256、opcache.max_accelerated_files=20000 - 数据库连接加持久化：
'params' => [PDO::ATTR_PERSISTENT => true]，同时 MySQL 端调大wait_timeout到 300 秒 - CLI 脚本单独设内存：
php -d "memory_limit=512M" think queue:work，不跟 Web 请求抢资源
