PhpStorm 不检测 PHP 运行时内存泄漏，仅监控自身 JVM 内存；查 PHP 内存泄漏需用 Xdebug memory 模式或 memory_get_usage() 打点，配合峰值统计与 GC 控制。
PhpStorm 本身不直接检测 PHP 运行时的内存泄漏，它只能监控自身 JVM 的内存使用；真正要查 PHP 代码里的内存泄露，得靠 Xdebug 的 memory 模式 + 手动比对快照，或用 memory_get_usage() 在关键路径打点。
PhpStorm 自身内存是否异常？先看 JVM 堆使用
很多人误以为“PhpStorm 卡”=“PHP 内存泄露”，其实可能是 IDE 自身吃光了内存。启动后按 Ctrl+Shift+A（Windows/Linux）或 Cmd+Shift+A（macOS），输入 “Show Memory Indicator”，勾选后状态栏会显示实时 JVM 堆占用。如果长期接近 -Xmx 设置值（比如你设了 -Xmx2048m，但常驻在 1950MB+），就要调大或清理：
- 编辑
phpstorm64.vmoptions（Linux/macOS 在bin/目录下，Windows 同理），把-Xmx提到-Xmx3072m（确保系统有足够物理内存） - 禁用非必要插件：进
Settings > Plugins，关掉Docker、Database Tools等重型插件 - 定期执行
File > Invalidate Caches and Restart > Just Restart，避免索引碎片拖慢响应
Xdebug memory 模式必须显式启用，profile 模式不管用
只开 xdebug.mode=profile 不会记录内存分配，必须包含 memory。否则 cachegrind.out.* 文件里看不到内存增长趋势，纯 CPU 时间排序毫无意义：
- 确认
php.ini中有且仅有：xdebug.mode=develop,memory（不能写成profile,memory，develop是前提） -
xdebug.output_dir必须指向一个 PHP 进程可写的目录，比如/tmp/xdebug，且提前chmod 777 /tmp/xdebug - CLI 脚本分析时，运行命令要带完整参数：
php -dxdebug.mode=memory -dxdebug.start_with_request=yes script.php - Web 请求需配合浏览器插件（如 Xdebug Helper）触发，且确保 PHP-FPM/Apache 配置中未覆盖
xdebug.mode
用 memory_get_usage() 打点比 Xdebug 快照更准、更快
Xdebug 的 memory 快照是全量堆快照，生成慢、文件大、难比对；而 memory_get_usage() 是轻量级探针，适合快速定位哪段逻辑突增内存：
立即学习“PHP免费学习笔记（深入）”；
- 在函数入口/出口加两行：
$start = memory_get_usage();和error_log("funcX: ".(memory_get_usage()-$start)." bytes"); - 注意用
memory_get_peak_usage()查峰值，避免被 GC 干扰判断 - 循环体内部慎用——高频打点会拖慢执行，建议只在可疑分支（如 if 条件成立时）插入
- 配合
gc_collect_cycles()强制触发回收后再测，排除 GC 延迟干扰
别信 Webgrind 的“内存占用”列，它显示的是累计分配量
Webgrind 解析 cachegrind 文件时，“Inclusive Memory” 显示的是该函数及其子调用**总分配量**，不是净增长。一个反复调用的小函数可能数值很高，但未必泄漏：
- 真正要盯的是：同一请求中，某函数的
Inclusive Memory随请求次数线性上涨 - 重点检查
static变量、全局数组追加、use闭包捕获大对象、未unset()的大数组引用 - 用
get_defined_vars()或gc_status()（PHP 8.0+）辅助验证变量生命周期
最易被忽略的是：Xdebug 的 memory 快照默认不包含 Zend 引用计数细节，无法直接看出循环引用；得靠 debug_zval_dump() 或手动构造最小复现脚本验证。
