FrankenPHP 1.2 Worker 模式在稳定性、配置粒度、资源控制和可观测性四方面显著增强：支持优雅退出与超时控制、线程与 Worker 数量解耦、新增请求级清理钩子、结构化日志与 Prometheus 指标暴露、OPcache 预加载兼容性加固。
FrankenPHP 1.2 的 Worker 模式相比 1.0 版本，主要在稳定性、配置粒度、资源控制和可观测性四方面做了实质性增强，并非仅是小修小补。官方 changelog 与源码比对（截至 2026 年 10 月）显示，这些优化直指早期 Worker 模式在生产落地时暴露的典型痛点。
更精细的 Worker 生命周期管理
1.0 版本中，worker 进程一旦启动，仅依赖 pm.max_requests 或信号被动终止，缺乏主动健康检查与优雅退出支持。1.2 引入了可配置的 graceful_timeout 和 max_execution_time 参数，允许你在 Caddyfile 中明确设定单个 worker 处理请求的最长持续时间与超时窗口。当达到阈值时，FrankenPHP 会等待当前请求完成后再关闭该 worker，避免连接中断或事务截断。
线程与 Worker 数量解耦，支持异构负载调度
1.0 默认将 num_threads 与 worker.num 绑定（如设为 8，则自动启用 8 个 worker 线程）。1.2 允许独立配置：
-
num_threads控制 Go 层并发处理 HTTP 请求的能力（影响静态文件、中间件、路由等非 PHP 逻辑吞吐）； -
worker.num单独控制 PHP worker 进程数量（专注业务执行），两者可按 I/O 密集型或 CPU 密集型场景分别调优。
例如，高并发但逻辑轻量的 API 服务可设num_threads 32+worker.num 8，避免 PHP 层成为瓶颈。
内置请求级状态清理钩子（实验性但可用）
虽然 FrankenPHP 仍不提供类似 Swoole 的 onRequest 钩子，但 1.2 在 frankenphp_handle_request() 调用前后新增了两个可选回调入口：
-
before_handle_request()：在每次请求分发前触发，适合重置静态变量、清空单例缓存、关闭上一请求遗留的fopen()句柄； -
after_handle_request()：响应发送后执行，可用于显式unset()大数组、调用apcu_clear_cache()或记录请求耗时。
这两个函数需在worker.php入口文件中定义，无需修改框架代码，降低了状态泄漏风险。
增强的运行时指标暴露与日志上下文
1.0 的日志较简略，难以定位长尾请求来源。1.2 默认启用结构化 worker 日志，每条记录包含：
- 请求 ID（跨 middleware 与 PHP 层一致）；
- worker PID 与启动时长（判断是否老化）；
-
bootstrap_ms字段（精确到毫秒的框架初始化耗时）； - 内存使用峰值（
memory_usage_peak），便于识别缓慢增长的泄漏。
配合caddy metrics端点，可直接采集frankenphp_worker_uptime_seconds、frankenphp_worker_requests_total等 Prometheus 指标。
OPcache 预加载兼容性加固
1.0 对 opcache.preload 的路径解析存在符号链接解析异常，在容器化部署中易失败。1.2 改进了 preload 脚本加载器，支持 realpath() 自动归一化，并新增 preload_check_interval 配置项，允许定期校验预加载文件的 mtime 变更，实现热更新感知（需搭配 opcache.revalidate_freq=0 使用）。
