PHP扩展内存泄漏主因是内存分配释放不匹配、zval生命周期管理不当、全局变量未清理、调试不足及析构异常；需严格配对emalloc/efree与malloc/free，正确操作zval引用计数与数据释放，RSHUTDOWN中清理静态资源，启用ZEND_MM_DEBUG验证，并禁止析构器抛异常。
如果您在开发PHP扩展时发现脚本执行后内存持续增长，进程RSS值不回落，或Valgrind报告大量未释放的堆块，则很可能是扩展中存在内存泄漏。以下是预防PHP扩展内存泄漏的关键实践：
一、严格匹配内存分配与释放函数对
PHP扩展中必须确保使用同一内存管理层级的函数配对调用：emalloc/efree用于PHP内部内存池，malloc/free用于系统级内存，二者不可混用。混用将导致efree无法识别malloc分配的地址，从而跳过释放逻辑。
1、所有通过emalloc、ecalloc、erealloc分配的内存，必须使用efree释放。
2、所有通过malloc、calloc、realloc分配的内存，必须使用free释放。
立即学习“PHP免费学习笔记（深入）”；
3、在资源析构器（如resource destructor）中检查zval成员是否为emalloc分配，若zval->value.str.val由emalloc分配，则必须用efree释放，不可用free。
二、正确管理zval生命周期与引用计数
zval结构体本身不自动管理其内部字符串、数组等数据的内存；其引用计数（refcount__gc）仅控制zval结构体的销毁时机，不触发深层数据释放。忽略zval数据字段的显式清理会导致底层字符串缓冲区、HashTable等长期驻留。
1、在zval赋值前调用Z_TRY_ADDREF_P()增加引用计数，避免浅拷贝后原zval释放导致悬垂指针。
2、在zval不再使用且需释放其所含数据时，调用ZVAL_NULL()或ZVAL_UNDEF()清空值并触发底层资源释放。
3、若手动维护zval字段（如Z_STR_P(zv)->val），必须在zval销毁前显式调用 zend_string_release(Z_STR_P(zv))。
三、谨慎处理全局变量与静态缓存
扩展中声明的全局指针或静态HashTable若存储了emalloc分配的对象（如zend_string、zval*），且未在模块shutdown阶段遍历释放，这些内存将在整个SAPI生命周期内持续占用，表现为常驻泄漏。
1、在PHP_RSHUTDOWN_FUNCTION中遍历所有静态HashTable，对每个元素调用对应释放函数（如zend_hash_destroy、zend_string_release）。
2、全局指针变量在模块初始化时置为NULL，在RSHUTDOWN中检查非NULL后执行efree，并立即置NULL。
3、禁止在MINIT中分配内存并保存至全局变量而不提供MShutdown对应释放逻辑。
四、使用Zend Memory Manager调试工具验证
启用ZEND_MM_DEBUG可使emalloc系列函数记录分配栈帧，并在请求结束时输出未释放块摘要。该模式下每次efree失败或重复释放均触发断言中断，是定位泄漏源头的直接手段。
1、编译PHP时添加--enable-debug --enable-zend-mt --enable-zend-mm=debug参数。
2、运行脚本后检查STDERR输出，查找“Leaks Detected”及对应backtrace行号。
3、在疑似泄漏代码段前后插入GC_COLLECT_CYCLE()强制触发垃圾回收，若泄漏量下降，说明问题与循环引用或延迟释放相关。
五、避免在对象析构器中引发异常或长跳转
PHP对象的__destruct方法或扩展注册的object handlers->dtor回调中若抛出异常、调用exit()或执行setjmp/longjmp，将跳过后续的zval清理与efree调用，导致关联内存永久泄漏。
1、析构器内禁用throw语句，改用日志记录错误状态。
2、避免在dtor中调用可能触发PHP错误处理机制的函数（如zend_error、php_printf）。
3、所有efree、zend_string_release等释放操作必须位于析构器最外层作用域末尾，且无任何分支跳过该行。
