在 Swoole、Workerman 等常驻进程框架的回调中调用 die() 或 exit() 会直接终止 Worker 进程，导致连接中断、状态丢失和频繁重启；应改用 return 或异常机制安全中断逻辑。
回调里用 die() 或 exit() 会直接杀死 Worker 进程
不能。在 Swoole、Workerman 等常驻进程框架的回调（如 onReceive、onMessage、onConnect）中调用 die() 或 exit()，会导致当前 Worker 进程立即终止，触发「意外退出」——日志里常见 WORKER EXIT UNEXPECTED，主进程随后拉起新进程补位，但已有连接中断、状态丢失、资源未清理。
-
die()和exit()是 PHP 的进程级终止函数，不是“退出当前请求”，而是终结整个执行上下文（即当前 Worker 进程） - 常驻进程模型下，Worker 进程要持续处理成百上千次请求，
die()相当于拔电源，不是关机 - 哪怕只在某个异常分支里写了一行
die("debug");，上线后遇到该分支就崩一次，监控会看到频繁重启
替代方案：用 return 或抛出异常来中断当前逻辑
真正需要的是“跳出当前回调执行”，而不是“干掉整个进程”。return 是安全的退出方式；若需统一错误处理，应配合异常 + try/catch。
- 在
onReceive回调里检测非法数据？直接return;即可，连接保持，后续消息仍可收 - 想返回错误响应给客户端？用框架提供的方法，比如 Swoole 中写
$server->send($fd, "error"); return; - 业务层校验失败需中止？抛出
Exception，并在顶层 catch 后return，避免穿透到进程层 - 切勿在
try块里die()—— 异常机制失效，错误无法捕获，进程照崩
为什么新手总在这里栽跟头？三个典型场景
因为开发习惯从 CLI 或 Web 环境迁移而来，误把常驻进程当“一次脚本”用。
- 调试时随手加
die("here");—— 框架没关连接、没清缓存、没释放协程上下文，进程就挂了 - 沿用老项目逻辑，把 Web 中的
exit(json_encode([...]))直接搬进 MQTTonMessage回调 —— Workerman 直接报WORKER EXIT UNEXPECTED - 在定时器回调（
addTimer）里调用exit()，以为只是停掉定时任务，结果整个 Worker 进程陪葬
检查与加固：快速定位和预防
别等线上崩了才找问题。主动扫代码、加约束、改习惯。
- 用
grep -r "die\|exit(" ./app/ --include="*.php"快速筛出风险调用点（注意排除 vendor） - 在 Worker 启动前注册
register_shutdown_function，记录error_get_last()，能抓到未捕获异常或静默 exit 导致的崩溃 - CI 阶段加入 PHP_CodeSniffer 规则，禁止在指定命名空间（如
App\Listener\）下使用die/exit - 团队共享一份《常驻进程禁用函数清单》，把
die、exit、sleep、pcntl_fork都列进去
die()，而是它藏在某次条件判断深处，只在特定并发路径下触发，复现难、日志少、排查耗三天。留个心眼，比事后救火强得多。 
