frankenphp worker模式下exit()会终止整个worker进程而非仅当前请求，导致主进程重启worker，应改用return或异常替代。
FrankenPHP Worker 模式下 exit() 会直接终止当前 worker 进程
FrankenPHP 的 Worker 模式（基于 SAPI frankenphp）不是传统 CGI 或 CLI，而是常驻内存的长期运行进程，每个请求由独立的协程或线程处理，但底层 worker 进程本身是复用的。此时调用 exit() 不会像 Web 环境那样“只结束本次响应”，而是触发整个 worker 进程退出 —— 因为 FrankenPHP 尚未对 exit() 做语义重写或拦截。
-
exit("error")会输出字符串并让 worker 进程以状态码 0 退出 -
exit(1)会静默退出，worker 进程返回状态码 1，FrankenPHP 主进程通常会拉起新 worker（取决于配置） - 即使在 handler 函数内部（如
onRequest回调里）调用，也无法被 try/catch 捕获，finally块不会执行 -
register_shutdown_function()和对象析构函数仍会运行，但之后进程即终止，无法继续服务后续请求
exit() 在 Worker 模式 vs CLI/Web 下的行为差异
关键区别不在 PHP 层，而在宿主环境如何响应进程退出：
- CLI：你看到
$?，脚本结束，无后续 - Web（Apache/FPM）：
exit()只终止当前请求生命周期，worker 进程继续等待下一个请求 - FrankenPHP Worker 模式：等效于 CLI 级别退出 —— 它把每个 worker 当作一个独立可重启的单元，不保证优雅回收或请求队列续传
常见误判场景：
- 以为
exit()能“中断当前请求但不影响 worker”，结果整个 worker 挂了，触发重建开销 - 在错误处理中写
exit("404");，导致 worker 频繁重启，日志里出现密集的 “worker exited with status 0” - 依赖
finally清理资源（比如关闭临时文件句柄），但该块根本不会执行
替代方案：用返回值或异常代替 exit()
FrankenPHP Worker 模式推荐显式控制流，而非进程级终止：
- 在 handler 中直接
return：结束当前请求，worker 继续运行 - 抛出
Throwable（如new RuntimeException("not found")）：由 FrankenPHP 捕获并转为对应 HTTP 状态（需配合http_response_code()或响应构造） - 若必须终止 worker（如配置加载失败），改用
posix_kill(getmypid(), SIGTERM)，更明确且可被主进程识别为“主动退出”
注意：FrankenPHP 从 v1.1 起已移除对 uopz_allow_exit() 的兼容，PHP 8.4+ 下 exit 是真函数，无法通过扩展禁用 —— 所以别试图“打补丁屏蔽 exit”，应重构逻辑。
容易被忽略的点：日志和调试陷阱
-
exit()后的file_put_contents()或error_log()调用大概率丢失，因进程已进入退出路径 - 使用
var_dump()+exit()调试时，输出可能被缓冲未刷出，尤其在非 CLI SAPI 下 - 如果 worker 因
exit()频繁重启，先检查是否在onWorkerStart或全局作用域里误写了exit()—— 这会导致 worker 根本无法进入请求循环
FrankenPHP 的 Worker 模式本质是“轻量级守护进程”，exit() 对它的意义更接近系统信号，不是流程控制语句。用错一次，就可能让整个服务抖动。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
