ThinkPHP内存溢出需先定位真因而非盲目调大memory_limit；通过memory_get_peak_usage(true)分段打点确认暴涨节点，结合错误日志行号、模板死循环、全量查询、Spreadsheet对象滥用、Swoole容器未重置等高频问题精准排查。
ThinkPHP内存溢出不是配个memory_limit就能完事的，它大概率是代码在某个环节把内存吃光了——比如导出Excel时加载整个Spreadsheet对象、模板里{include}嵌套死循环、或一次查出5万条记录塞进数组。直接调高限制只是拖延报错时间，甚至可能触发系统OOM Killer杀进程。
怎么确认真是内存溢出，而不是误判？
别一看到Fatal error: Allowed memory size of 134217728 bytes exhausted就改配置。先用memory_get_peak_usage(true)在关键位置打点：
- 入口文件开头、控制器方法开头、数据库查询后、模板渲染前、响应输出前各加一行
echo memory_get_peak_usage(true) . "\n"; - 对比各处数值，看哪一步突然暴涨——比如
Db::name('log')->select()之后从20MB跳到300MB，问题就在这儿 - 检查错误日志里的
in /path/to/ThinkTemplate.class.php on line 123这类线索：ThinkPHP 3.x 的模板引擎死循环很常见，4.x/6.x 则多见于自定义标签或view()->fetch()传入超大数组 -
get_included_files()看看是否意外加载了上百个文件（尤其用了vendor/autoload.php又手动require一堆类）
ThinkPHP里哪些操作最吃内存？
这些场景在TP项目中高频触发真实内存压力：
- 导出Excel用
PhpSpreadsheet：newSpreadsheet()本身就会占几十MB，再填几千行数据，128M默认值根本不够。必须放弃高层API，改用XmlWriter直写sharedStrings.xml和sheet1.xml，每行flush()到php://output - 模板中
{include file="xxx"}嵌套过深或带变量传递，ThinkPHP 3.x 的ThinkTemplate解析器会递归展开并缓存全部内容；换成原生<?php include 'xxx.html'; ?>可绕过 - 用
Db::name('huge_table')->select()查全表——哪怕加了where，如果没索引或结果集超1万行，PDO默认缓存全量结果；改用paginate(100)或cursorPaginate()（TP6.1+） - Swoole环境下没重置容器：
Container::getInstance()在Worker长生命周期里不断bind()新实例却不释放，$container->setInstances([])和$container->forget()得配合用
memory_limit到底在哪设才真正生效？
ThinkPHP跑在不同SAPI下，配置优先级和生效方式完全不同：
立即学习“PHP免费学习笔记（深入）”；
- CLI模式（如
php think queue:work）：启动时加-d memory_limit=512M最可靠，例如php -d memory_limit=1G think export:run；ini_set()可能已失效（因分配失败发生在函数调用前） - PHP-FPM（Nginx常用）：改
/etc/php/8.1/fpm/php.ini里的memory_limit，然后sudo systemctl restart php8.1-fpm；.user.ini也有效，但需确认user_ini.filename = ".user.ini"已开启 - Apache模块：改
/etc/php/8.1/apache2/php.ini并重启apache2；.htaccess里写php_value memory_limit 512M仅当AllowOverride All启用时才管用 - 代码内
ini_set('memory_limit', '512M')只对后续内存分配生效，且不能超过php.ini里设的硬上限（除非设为-1，但线上禁用）
真正难处理的从来不是“怎么调大”，而是“为什么这行file_get_contents($url)返回的JSON一解码就爆内存”——那个$url返回的是200MB日志文本，你却当成小配置在处理。定位到具体函数、具体参数、具体数据规模，比盲目加内存重要十倍。
