报错不带文件行号时，需先区分“一次分配失败”与“长期累积撑爆”：有明确行号多为单次操作超限，无行号或指向vendor则可能是内存被前序代码逐步耗尽。
报错不带文件行号？先确认是不是真内存溢出
看到 Fatal error: Allowed memory size of xxx bytes exhausted 就去改 memory_limit，容易白忙活。真正要先判断：这是“一次分配失败”，还是“长期累积撑爆”？
- 如果错误信息里明确写了
in /path/to/xxx.php on line 123，大概率是某次操作（比如json_decode()、file_get_contents()）瞬间申请超限，问题就在那一行附近 - 如果只报错、没位置，或者堆栈指向
vendor/某个扩展内部（如thinkphp/library/think/template/Template.php），更可能是前序代码已悄悄吃掉大量内存，最后一步只是压垮骆驼的稻草 - 开 xdebug 的话，关掉
xdebug.mode=debug—— 它本身就会显著增加内存开销，尤其在模板编译或大数组 dump 时
TP5.1 里最容易吃内存的三个地方
ThinkPHP 5.1 的运行机制决定了某些写法会比普通 PHP 更“贪吃”内存，尤其在开发环境未调优时：
-
Db::table('user')->select()查几万条数据 → 全量加载进数组，每条记录还带 PDOStatement 引用，10 万行轻松干掉 300M+；换成Db::table('user')->chunk(1000, function($users) { ... })流式处理 - 模板里写
{volist name="list" id="item"}{volist name="item.children" id="child"}{/volist}{/volist}，但list和item.children实际是同一份数据引用 → 内层volist会重复解析，内存翻倍；确保嵌套时name值不重名，且数据结构分层清晰 - 在控制器里反复调用
Loader::import()或手动require同一文件，尤其配合自定义标签或行为钩子时 →get_included_files()一查可能发现加载了 200+ 文件，每个都占几 KB，积少成多；优先用自动加载，避免显式引入
怎么快速测出哪段代码最耗内存
别靠猜，加三行 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";
对比数值跳变——比如从 8M 跳到 120M，那中间那段就是嫌疑区。注意：TP5.1 的模板编译缓存若损坏（比如 Runtime/Cache/ 下残留半截 .php 文件），也会导致编译器反复尝试、不断 malloc，表现为峰值陡升但无明显业务代码。
临时救急但别上生产
开发调试时可快速绕过，但上线前必须清理根源：
- Web 请求中，在入口文件或控制器开头加
ini_set('memory_limit', '512M');—— 仅本次请求生效，比改php.ini安全 - CLI 命令行执行时用
php -d memory_limit=1G think queue:work—— 队列任务常需更多内存，但记得检查是否真需要，而非掩盖泄漏 - 绝对不要写
ini_set('memory_limit', '-1')上线，尤其 Nginx + PHP-FPM 环境下，一个失控请求可能拖垮整个 worker 进程池
真正棘手的是那些不报错但缓慢增长的内存占用，比如循环中不断 new 对象却没 unset，或事件监听器注册后没解绑。这类问题不会立刻崩，但跑几天后 memory_get_peak_usage() 会持续走高，得靠 gc_collect_cycles() 配合日志打点才能揪出来。
