php扩展中zval引用计数必须显式管理，需用z_try_addref_p安全递增、z_delref_p递减，避免悬空指针或内存泄漏；循环引用须改用zend_weakref_t弱引用并注册析构清理；资源释放须严格遵循“先断引用、再清内存”顺序。
理解PHP扩展中zval的引用计数行为
开发PHP扩展时，若直接操作zval却忽略refcount管理，极易导致内存泄漏或提前释放——比如在返回对象前未调用Z_TRY_ADDREF_P，调用方拿到的就是悬空指针。
每个zval结构体包含refcount__gc字段，它不是简单的整数，而是原子操作保护的计数器。扩展中所有对zval的赋值、传参、返回，都必须显式干预该计数。
方法一：使用Z_TRY_ADDREF_P宏安全递增计数
Z_TRY_ADDREF_P(zv); // 仅当zv非NULL且类型支持引用计数时生效，避免对integer等标量误操作
方法二：手动检查并递增（仅限极少数需精细控制的场景）
if (Z_TYPE_P(zv) == IS_OBJECT || Z_TYPE_P(zv) == IS_ARRAY || Z_TYPE_P(zv) == IS_STRING) {
Z_ADDREF_P(zv);
}
【Z_ADDREF_P不检查类型，对IS_LONG调用会破坏内存】
扩展中避免循环引用的三步实操
PHP用户代码中的循环引用由GC自动处理，但扩展内部若让zval互相持有（如资源对象内嵌回调zval），GC无法识别——因为这些引用不在PHP符号表中，属于C层私有结构。
第一步：识别潜在循环链路
检查是否在资源结构体（如my_resource_t）中直接存储zval*或zval成员，尤其是回调函数、闭包、配置数组这类可能反向引用宿主对象的类型。
第二步：改用弱引用模式
将强引用zval*替换为zend_weakref_t句柄：
zend_weakref_t *wr = zend_weakref_create(zv);
后续需通过zend_weakref_get(wr, &tmp_zv)获取有效zval，失败则说明原zval已被回收。
第三步：注册析构回调清理弱引用
在资源释放函数中调用zend_weakref_destroy(wr)，否则弱引用句柄本身会持续占用内存。
手动触发GC并验证扩展内存行为
扩展调试阶段必须验证垃圾是否被正确回收，不能依赖脚本结束才释放——尤其在长期运行的Swoole协程环境中。
执行gc_collect_cycles()前，先确保扩展已启用GC：
if (!GC_G(gc_enabled)) {
zend_error(E_WARNING, "GC disabled, memory leaks may persist");
return;
}
调用gc_collect_cycles()后立即检查内存变化：
size_t before = zend_memory_usage(0);
gc_collect_cycles();
size_t after = zend_memory_usage(0);
if (after >= before) { /* 未回收，需排查zval引用残留 */ }
注意：gc_collect_cycles()返回本次回收的周期数，返回0不代表无垃圾，只代表未发现可回收的循环结构。
扩展中释放资源的强制顺序
PHP扩展资源销毁必须遵循“先断引用、再清内存”的硬性顺序，颠倒会导致zval访问已释放内存。
① 调用Z_DELREF_P清除所有对该zval的扩展内引用
② 若zval是对象，检查是否持有扩展分配的私有资源（如curl handle、socket fd），在此步关闭并置NULL
③ 调用zend_object_std_dtor或对应资源dtor函数
④ 最后调用efree()释放扩展自身分配的struct内存
这一步不可跳过：若在②之前调用efree，后续dtor中访问私有资源字段就是野指针。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
