应运行frankenphp -m获取唯一可信的已加载扩展清单，重点核查opcache、pdo_mysql、curl是否在列，并检查extension_dir路径及扩展是否用frankenphp-build重编译以确保ABI兼容。
确认 FrankenPHP 实际加载的扩展是否含可疑模块
FrankenPHP 的扩展加载路径和初始化时机与传统 PHP 不同，很多 C 扩展（如 apcu、redis、swoole）若未用 frankenphp-build 重编译，会静默失败或引发底层内存管理异常。先验证它到底加载了哪些扩展：
- 运行
frankenphp -m—— 这是唯一可信的清单，php -m可能查的是系统 PHP 环境 - 检查输出中是否有
undefined symbol: zend_object_std_init类错误（说明扩展 ABI 不兼容） - 重点盯住
opcache（必须启用）、pdo_mysql、curl是否在列；apcu默认不支持，redis需用php8.2-franken-redis包
用 Valgrind 检查扩展层 C 代码的内存行为
PHP 层的 memory_get_usage() 看不到扩展自己 malloc 的内存，必须下到 C 层。Valgrind 是目前最可靠的手段，但需注意 FrankenPHP 是 Go + PHP 嵌入式运行时，得绕过 Go 部分干扰：
- 启动 FrankenPHP 时加
--debug参数，并确保它以单进程模式运行（禁用 worker 多实例） - 用
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./frankenphp -c caddyfile启动 - 触发疑似泄漏的请求（如反复调用含该扩展的 API），然后
kill -SIGTERM干净退出 - Valgrind 报告里重点看
definitely lost和possibly lost行，对应扩展的.so文件名和调用栈
在 PHP 脚本中隔离测试扩展调用并监控内存拐点
不要直接在线上测，写一个最小可复现脚本，把扩展调用和内存测量绑死：
- 新建
test-ext-leak.php，内容为：<?php $start = memory_get_usage(true); for ($i = 0; $i < 100; $i++) { // 替换为你要测的扩展调用，例如： // $redis->set('key', str_repeat('x', 1024)); // $pdo->query('SELECT 1'); } $end = memory_get_usage(true); echo "Delta: " . ($end - $start) . " bytes\n"; ?> - 执行
php test-ext-leak.php和frankenphp run test-ext-leak.php对比结果——如果后者内存增长显著更高，基本锁定是 FrankenPHP 运行时与该扩展交互出问题 - 配合
gc_collect_cycles()和gc_mem_caches()在循环末尾插入，看是否缓解；若无改善，大概率是扩展本身未适配嵌入式 SAPI
检查 extension_dir 路径与 Zend 引擎初始化顺序
FrankenPHP 启动时会强制设置自己的 extension_dir（通常是 /usr/lib/php/8.2/franken），若扩展仍从旧路径加载，会导致符号解析错乱、zval 生命周期管理失效：
立即学习“PHP免费学习笔记（深入）”；
- 运行
frankenphp --info | grep extension_dir确认实际路径 - 进该目录，用
file *.so查看每个扩展是否链接了libfrankenphp.so（而非libphp.so） - 若扩展是自己编译的，必须用 FrankenPHP 提供的
frankenphp-build工具，不能沿用phpize && ./configure流程 - 启动日志里出现
ZEND_MODULE_POST_ZEND_DEACTIVATE_N相关 warning，说明扩展注册了错误的生命周期钩子，会在 worker 长期驻留时不断累积引用
第三方扩展的内存泄漏往往不是“没释放”，而是“释放了但没被回收”——因为 FrankenPHP 的 PHP 运行时嵌在 Go 进程里，扩展依赖的某些 Zend 内部全局状态（如 EG(current_execute_data)）在请求边界不清晰，导致 GC 根扫描失效。所以别只盯着 unset，先确保扩展本身是 FrankenPHP 认证兼容的版本。
