摸清 memory_get_usage 的底细，告别 PHP 内存焦虑

跑脚本时突然抛出 Allowed memory size exhausted，第一反应往往是盲目拉高 memory_limit。真想根治问题，得先看清程序实际吞掉了多少内存。memory_get_usage() 就像一块直白的内存电压表，但很多人拿它测出的数据，反而把排查带进了歧路。

调函数不传参时，返回的是 Zend 引擎当前使用的内存量。这个数值里混杂了符号表、预分配缓冲区和对象池，并不等同于你手头的变量占了多少字节。如果你的目的是追踪实际业务数据的体量，记得传入 true，它会统计进程向操作系统申请的总内存。日常轻量调试用默认参数足够，碰到 Swoole 常驻、Guzzle 长连接或 GD 图像处理时，再切到 true 交叉比对。别死磕单次数值，内存分配天生带有碎片特征，上下浮动几十 KB 属正常呼吸。

循环吞吐万级数据时，当前水位可能一直平稳，真正的隐患往往藏在峰值里。配合 memory_get_peak_usage() 记录关键节点的前后差值，比盯着实时跳动靠谱得多。编写队列消费者或定时任务，建议在入口初始化完成后打一次点，任务执行完毕后打第二次点，两者相减才是纯业务逻辑的真实消耗。循环体内频繁拼装的大型数组，用完务必 unset() 切断引用链，能显著压低后续读数的基准线。

拿到数据后如何落地排查？按这三步走效率最高：定基线——脚本开头清空静态变量后读取一次初始值作为零点位；切断点——每次拉取第三方接口、导入 CSV 或执行 fetchAll() 后立即打点，用差值锁定吞噬内存的重型模块；压边界——用相同数据集重复运行三次，观察峰值曲线是否稳定逼近配置上限。若发现某段代码因全量加载关联数组导致水位失控，果断改为分批查询或生成器逐行解析，把一次性堆砌拆成流式管道。

还有一个容易被忽略的现象：GC 触发时读数会突然跳水。当你以为内存快要见底却突然降下来，多半是后台回收机制清除了游离对象。此时无需手动干预，让 PHP 调度器自行判断时机最稳妥。顺便提一句，某些底层扩展或 C 语言编写的扩展会绕过 Zend 内存管理器直接调用系统 malloc，这类情况只有 true 参数才能如实上报。

内存排查从来不是凑数字的算术题，而是拆解执行流的工程活。memory_get_usage() 提供的是线索坐标，不是最终判决。把打点思维嵌进核心链路，配合分批拉取与引用清理，那些半夜跳闸的 OOM 告警，自然会远离你的开发节奏。