FrankenPHP下WordPress后台GC行为几乎不影响响应，真正瓶颈是框架初始化、插件钩子、数据库查询和远程资源阻塞；因常驻进程+opcache稳定，GC触发频次远低于PHP-FPM。
FrankenPHP下WordPress后台的GC行为是否显著影响响应
不会。WordPress在FrankenPHP上运行时，PHP的垃圾回收（GC）本身几乎不会成为后台卡顿的可观测原因——真正拖慢后台的是框架初始化、插件钩子遍历、数据库查询和远程资源阻塞，不是GC周期。
为什么GC压力在FrankenPHP里反而比PHP-FPM还低
FrankenPHP是常驻进程模型，PHP解释器不随请求重启，opcache长期有效，gc_collect_cycles()调用频次大幅下降。而PHP-FPM每次请求都要从头加载全部类、配置和插件代码，GC触发更频繁（尤其当插件滥用unserialize()或大量动态创建对象时）。
关键点：
- FrankenPHP默认启用
opcache.enable_cli=1和opcache.memory_consumption足够大（通常128M+），类定义和opcode缓存稳定，避免反复解析带来的临时对象堆积 - WordPress后台请求中，绝大多数变量生命周期短（如
$post,$wp_query），PHP的引用计数机制能即时回收，根本等不到GC介入 - 只有极少数场景会触发强制GC：比如某个插件在
admin_init里用json_decode($huge_json, true)生成嵌套几百层的数组，又没unset，才可能让GC周期变长
你真该盯住的三个后台性能黑洞
别花时间调zend_gc_disable()或改gc_threshold——这些操作不仅无效，还可能破坏内存稳定性。实际排查请优先看：
立即学习“PHP免费学习笔记（深入）”；
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
-
wp-admin/admin-ajax.php被插件高频轮询（如实时通知、监控类插件），造成并发连接堆积，FrankenPHP的worker队列被占满 - 主题或插件在
wp_enqueue_scripts或admin_enqueue_scripts里无条件加载大型JS（如完整版tinymce或block-editor依赖），且未做wp_script_add_data(..., 'strategy', 'defer') - 数据库查询未走索引，特别是
wp_options表被插件滥用get_option('large_serialized_array')，单次查询耗时超300ms——FrankenPHP再快也得等MySQL返回
一个快速验证GC是否真在捣鬼的方法
在wp-config.php顶部加两行：
ini_set('log_errors', 1);
ini_set('error_log', '/tmp/php-gc-debug.log');
然后在任意后台页面URL后加?debug-gc=1，并在主题functions.php里加：
if (isset($_GET['debug-gc'])) {
error_log("GC status: " . json_encode(gc_status()), 3, '/tmp/php-gc-debug.log');
error_log("Memory: " . memory_get_usage() . "/" . memory_get_peak_usage(), 3, '/tmp/php-gc-debug.log');
}
刷新几次后台，检查/tmp/php-gc-debug.log。如果collected字段始终为0或个位数，且memory_get_peak_usage稳定在20–40MB之间，说明GC完全不是瓶颈。
真正要命的，往往是那个没写WHERE条件的WP_Query，或者仍在调用http://fonts.googleapis.com的旧主题CSS。
