快速定位php内存问题需用memory_get_usage()和memory_get_peak_usage()手动打点，结合gc_collect_cycles()、预分配数组、流式处理大结果集、优化opcache配置及cli下主动gc等手段。
怎么快速定位 PHP 脚本吃内存的罪魁祸首
用 memory_get_usage() 和 memory_get_peak_usage() 手动打点，比开 Xdebug 或 Blackfire 更快、更轻量。尤其适合线上临时排查——只要加几行日志，就能看出哪段逻辑突然涨了几十 MB。
-
memory_get_usage(true)返回当前实际分配的内存（含未释放的碎片），比默认 false 更准 - 在关键函数前后各调一次，差值就是该段代码净增内存；注意别只看峰值，有些对象释放晚但占着不放
- 避免在循环里高频调用——它本身有开销，每千次调用可能多耗 1–2 MB
- 配合
get_defined_vars()快照变量表（慎用！只在怀疑某处变量爆炸时临时加）
大数组和对象引用是 PHP 内存泄漏最常见原因
PHP 的引用计数机制在遇到循环引用时不会自动回收，unset() 也不一定立刻释放内存——特别是对象属性互相持有、或闭包捕获了大变量。
- 用
gc_collect_cycles()主动触发垃圾回收，但别在循环里狂调，它本身耗 CPU - 数组不要用
$arr[] = $big_data不停追加，改用预分配：$arr = array_fill(0, $count, null)，减少 realloc 次数 - 读数据库大结果集时，别用
fetchAll()全塞进内存；改用fetch()单条处理，或 PDO 的PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false - 传参时小心
&$var，尤其是传给第三方库——很多 SDK 内部会缓存引用，导致你本以为已丢弃的对象一直活着
OPcache 配置不当反而让内存更紧张
OPcache 默认开启，但若 opcache.memory_consumption 设得太小，频繁满载会导致脚本反复编译+淘汰，反而推高内存波动。
- 查当前使用：访问
opcache_get_status()，重点看memory_usage.used_memory和opcache_statistics.opcache_hit_rate - 如果命中率低于 90%，优先调大
opcache.memory_consumption（如从 64M → 128M），而不是关 OPcache -
opcache.max_accelerated_files太小会导致文件哈希冲突，强制降级为全量扫描，间接增加内存压力 - 开发环境建议关掉
opcache.validate_timestamps = 1，否则每次请求都检查文件修改时间，触发额外内存分配
CLI 模式下没自动 GC，得自己兜底
Web 请求结束时 PHP 会清场，但 CLI 脚本跑完不退出（比如队列消费者、定时任务），对象和静态变量会长期滞留。
立即学习“PHP免费学习笔记（深入）”；
- 长运行脚本中，每处理 N 条任务后主动调
gc_collect_cycles()，N 根据单次内存增长量定（比如每次涨 2MB，就设 N=50） - 避免在类里用
static $cache = []缓存大量数据；改用外部缓存（Redis）或按需加载 -
register_shutdown_function()里清理资源不可靠——脚本被exit()或信号中断时不一定执行 - 用
pcntl_signal()捕获SIGTERM做优雅退出，比依赖自动回收更可控
真正难搞的不是峰值高，而是内存不回落——那基本锁定在引用没断、资源没 close、或扩展层有 bug。先确认是不是你自己写的循环引用，再怀疑扩展或 PHP 版本。
