FrankenPHP 运行 WordPress 时内存常驻更高但单请求开销更低：传统 PHP-FPM 按需启停进程导致重复加载与碎片，FrankenPHP worker 模式常驻加载插件、OPcache 和对象，首字节更快但初始多占30–60MB；实测2GB VPS下，FrankenPHP 总RSS更稳（420MB vs 650MB），OOM风险更低，但需调大opcache、外接Redis缓存并警惕静态变量内存泄漏。
FrankenPHP 运行 WordPress 时，常驻内存比 Nginx + PHP-FPM 更高，但单位请求的内存开销更低、更稳定——这不是“高了还是低了”的简单对比，而是内存使用模型的根本切换。
FrankenPHP 的内存行为和 WordPress 的适配逻辑
传统 PHP-FPM 是“按需拉起 + 请求后销毁”，每个 worker 进程跑完一个请求就释放大部分内存（但不完全归还给系统，有碎片和缓存残留）。WordPress 在这种模式下，每次请求都要：
- 加载全部插件和主题
- 初始化
wp-settings.php和核心对象（$wp,$wp_rewrite,$wp_query） - 重建
WP_Object_Cache（非持久化时是空的）
这些动作导致单次请求 CPU 开销大，但内存峰值短、进程间不共享、整体 RSS 增长缓慢（尤其 pm = dynamic 且 pm.max_spare_servers 控制得当时）。
而 FrankenPHP 在 worker 模式下（必须开启才能发挥优势）会让整个 WordPress 应用常驻内存。它会：
立即学习“PHP免费学习笔记（深入）”；
- 一次性加载所有插件、主题、配置和 OPcache 编译后的脚本
- 复用已初始化的全局对象（如数据库连接、路由规则、重写规则）
- 把
WP_Object_Cache留在内存里（若未用 Redis/Memcached，就是进程级缓存）
这意味着：
✅ 启动开销归零，首字节响应更快；
⚠️ 但初始内存占用更高（通常多出 30–60 MB），且不会随请求结束自动回落。
php-fpm vs frankenphp 内存实测差异点
-
php-fpm的内存是“离散抖动型”：你看到ps aux | grep php-fpm里多个进程 RSS 在 40–70 MB 波动，总和可能达 500 MB+，但其中大量是重复加载的 OPcache、插件代码、autoload 类映射 —— 它们彼此隔离、无法复用。 -
FrankenPHP的内存是“集中常驻型”：一个 worker 进程启动后 RSS 稳定在 80–120 MB（取决于插件数量和 OPcache 配置），多个 worker 共享部分只读段（如 OPcache 字节码），实际总内存增长呈亚线性。
举个真实场景：
一台 2 GB 内存的 VPS 跑 WordPress + WooCommerce：
-
php-fpm（pm = dynamic,max_children = 10）：平均 RSS 总和约 650 MB，但突发流量时容易触发 OOM Killer（因瞬时 fork 多个新进程）； -
FrankenPHP（workers.count = 4,opcache.enable=1）：稳定 RSS 总和约 420 MB，无 fork 开销，OOM 风险显著降低。
容易被忽略的三个内存陷阱
-
opcache.memory_consumption必须显式调大（默认 128 MB 不够 WordPress 插件生态），否则 OPcache 频繁满驱逐，反而加重常驻进程负担； - WordPress 的
wp_cache_set()默认存进进程内存，worker 模式下若没接外部缓存（Redis），多个 worker 会各自维护一份缓存副本 —— 看似省了初始化，实则浪费内存； -
frankenphp不自动清理$_SESSION或static变量跨请求残留，某些插件（尤其是老版会员/购物车）可能把用户数据堆在常驻内存里，越跑越胖。
FrankenPHP 不是让 WordPress “更省内存”，而是让它“更确定地用内存”。你得接受它启动时多占一点，换来的是不再为每个请求重复烧 CPU、不再被 FPM 的进程震荡拖垮 —— 尤其当你的站点启用了十几个插件、又开了 WP Super Cache 以外的动态逻辑时，这个 trade-off 很值。
