unset($var) 不等于内存释放，因其仅减引用计数且不处理循环引用；gc_collect_cycles() 非万能，仅在常驻进程中按需触发，且依赖根缓冲区积满或手动调用，返回0不代表无泄漏。
unset() 不等于内存释放，gc_collect_cycles() 也不是万能清道夫——PHP 垃圾回收的核心矛盾从来不是“学不学得会”，而是“在什么场景下必须干预、又该干预到哪一步”。
为什么 unset($var) 后 memory_get_usage() 没变化？
因为 unset() 只是从符号表删名字，并把对应 zval 的 refcount__gc 减 1；是否真释放，取决于减完是不是 0，且该 zval 是否属于循环引用链。
- 标量（
int、float、bool）在 PHP 7+ 中不参与引用计数，refcount恒为 0，unset完全无 GC 效果 -
string字面量（如'hello'）是 interned string，refcount恒为 1，unset不动它 - 数组或对象中嵌套了彼此引用（如
$a['child'] = $b; $b['parent'] = $a;），unset($a, $b)后两者refcount仍为 1，内存卡住不动 - 函数返回后局部变量自动
unset，但若其值被闭包捕获或写入全局静态变量，refcount 不归零，照样不释放
怎么确认是不是循环引用导致的假性内存泄漏？
靠 xdebug_debug_zval() 看 refcount，再用 gc_status() 查根缓冲区状态——这是最直接的诊断路径。
- 先装 XDebug（CLI 下
php -m | grep xdebug确认），否则xdebug_debug_zval()直接报错 - 构造疑似循环结构后调用
xdebug_debug_zval('a')，若输出refcount=1, is_ref=0但你确定已unset所有外部引用，基本可断定进了循环链 - 紧接着执行
var_dump(gc_status()['roots'])：值 > 0 表示已有节点进入 GC 根缓冲区，等待周期扫描 - 注意：
gc_status()在 PHP 7.3+ 才返回完整数组，旧版本只返回布尔值，别白忙
什么时候该手动调用 gc_collect_cycles()？
仅在常驻进程（Swoole Worker、Workerman、PHP-PM）里有必要主动触发；短生命周期 CLI 脚本几乎不需要——脚本结束时 Zend 引擎会批量清理所有局部 zval。
- 典型适用场景：长连接处理循环中反复构建大数组/对象图（如解析 JSON 树、组装响应体），且中间存在父子/上下级引用关系
- 不要每轮循环都调：
gc_collect_cycles()是同步阻塞操作，开销不小；建议每处理 N 次请求（如 50–100）或内存增长超阈值（memory_get_usage() > 20M）后调一次 - 调之前先
gc_enable()确保没被关掉（某些框架启动时会静默gc_disable()） - 返回值是整数：表示本次回收的循环节点数；返回 0 不代表没垃圾，可能只是还没积满根缓冲区阈值（默认 10000）
zend.enable_gc 和 gc_enable() 有什么区别？
前者是 php.ini 级配置，影响进程全局；后者是运行时开关，只对当前请求/协程生效。二者不等价，也不能互相替代。
-
zend.enable_gc = 0在 php.ini 中设死 → 即使调gc_enable()也无效，gc_status()始终返回enabled => false -
gc_disable()只是暂停当前执行上下文的 GC 注册逻辑，已进根缓冲区的节点不会被清空，下次gc_enable()后仍会参与扫描 - CLI 模式下默认开启 GC，但 Swoole 的子进程 fork 后可能继承父进程 GC 状态，需在
onWorkerStart里显式gc_enable()保险 - 别在热代码路径里反复
gc_enable()/gc_disable()切换——这不是性能优化，是给自己埋竞态雷
真实问题往往藏在「以为释放了」和「其实还挂着」之间的那层 refcount 数值里。盯住 xdebug_debug_zval() 输出，比读十遍文档都管用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
