memory_limit调高只是临时绕过报错，真正需定位内存泄漏点：用memory_get_peak_usage()测峰值、检查循环引用、未关闭句柄、全量加载等；必须调限时应按需分层设置，避免-1。
memory_limit 不是救命稻草，调高它只是临时绕过报错，掩盖了真正吃内存的代码逻辑。真要解决问题，得先确认是不是真的内存耗尽，再决定动配置还是改代码。
怎么判断是不是真内存溢出？
别一看到 Fatal error: Allowed memory size of XXX bytes exhausted 就去改 memory_limit。先打点测真实占用：
- 在脚本开头、关键循环前后、大操作（如
json_decode()、file_get_contents()）之后，加echo memory_get_peak_usage(true)看峰值 - 错误日志里带具体文件和行号？大概率是某次分配失败，不是整体撑爆；如果只报错不带位置，可能是前序残留或扩展干扰（比如开着
xdebug.mode=debug） - 用
get_included_files()检查是否意外加载了上百个文件——重复require也会悄悄吃光内存 -
var_dump()或print_r()调试大数组时触发 OOM？删掉那行就恢复，说明不是代码问题，是调试副作用
哪些场景必须调 memory_limit？怎么调才安全？
图像处理、Excel 导出、单次解析 GB 级 JSON —— 这类任务确实需要临时放宽限制，但必须「按需、分层、可撤回」：
- Web 请求中优先用
ini_set('memory_limit', '512M')，只影响当前请求，且要在任何大操作前调用（已超限时调用会静默失败） - CLI 脚本最可靠：运行时加
php -d memory_limit=1G script.php，不污染全局配置 - PHP-FPM 环境下，在对应 pool 的
www.conf里设php_admin_value[memory_limit] = 256M，比改php.ini更精准 - 绝对不要设成
-1：PHP 底层仍受系统malloc限制，且会掩盖循环引用、句柄泄漏等深层问题
为什么 unset() 了变量，内存还不降？
PHP 垃圾回收对循环引用无效，unset() 只是断开变量名指向，对象本身若被其他地方强引用着，就不会释放：
立即学习“PHP免费学习笔记（深入）”；
- 常见陷阱：
$child->parent = $this+$this->children[] = $child，形成闭环；必须手动打断：$child->parent = null、$this->children = [] - PDO 查询后没调
$stmt->closeCursor()，结果集缓存一直占着内存；文件句柄没关fclose($fp)，底层缓冲区也持续驻留 - 对象里存了大数组或资源句柄，
__destruct()里没清理，实例销毁后内存照样不归还 - 生成器（
yield）能缓解，但若在foreach外保留了对生成器的引用，整个迭代上下文都会滞留
数据库和文件操作最容易踩内存坑
这两类操作占 PHP 内存问题的七成以上，核心原则是「不全量加载」：
- 查百万级数据时，禁用
PDO::FETCH_ASSOC全缓存，改用游标分页：SELECT * FROM t WHERE id > ? ORDER BY id LIMIT 1000，并确保PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = false - 读大文件别用
file_get_contents()，改用fopen() + fgets()流式逐行；或封装成生成器：function readLargeFile($f) { $h = fopen($f, 'r'); while (($l = fgets($h)) !== false) yield $l; fclose($h); } - 解析超长 JSON 时，
json_decode($json, true, 512, JSON_BIGINT_AS_STRING)控制深度和字符串处理，避免整树加载；更重的场景换流式解析器（如jsonstream类库） - 用
array_splice()分片处理大数组后，立刻unset()子集变量，别等脚本结束才靠 GC
真正难处理的从来不是配置数字，而是那些看不见的引用链、没关的句柄、没清的缓存——它们不会报错，但会让内存缓慢爬升直到某次 new 或 malloc 直接失败。
