Worker模式下dd()和dump()仍可用但行为变化：dd()终止当前请求上下文而非进程，需显式启用worker_mode:true才支持Blade中@dd()，滥用会阻塞worker线程，注释中dd()也可能被解析导致启动失败。
Worker模式下dd()和dump()仍可用，但行为有隐性变化
能用，但不是“照常工作”。FrankenPHP Worker模式让PHP进程常驻内存，dd()调用后不会像传统FPM那样彻底退出进程，而是终止当前请求上下文、清空本次请求的变量作用域，然后等待下一个请求。这意味着：dd()仍会输出并中断当前请求，但整个worker线程不会崩溃或重启；dump()也照常输出，且不影响后续请求处理。
Blade模板里@dd()必须配合worker_mode: true配置
FrankenPHP默认以“普通模式”启动PHP运行时，此时Blade中的@dd()和@dump()可能不触发——因为Caddy未启用PHP的完整生命周期钩子。必须在Caddyfile或frankenphp.yaml中显式开启worker支持：
php: worker_mode: true
否则你会遇到：
-
@dd($user)在页面上完全无输出（不是白屏，是静默跳过） - 控制器中
dd($data)仍有效，但Blade层调试能力失效 - 错误信息不会报错，只会“消失”，排查时容易误判为变量为空
dd()在循环或高频请求中可能掩盖worker复用问题
Worker模式的核心价值是复用已初始化的框架容器、配置、连接池等。但如果你在中间件或全局服务中滥用dd()，比如写在handle()方法开头：
立即学习“PHP免费学习笔记（深入）”；
public function handle($request, Closure $next) {
dd('middleware hit'); // ❌ 每次请求都卡在这
return $next($request);
}
表面看只是调试，实际会导致：
- worker线程被阻塞，无法处理排队中的其他请求
- 监控指标里
frankenphp_worker_busy持续为1，frankenphp_worker_queue_length不断上涨 - 看似“单点调试”，实则把worker退化成串行处理，性能反不如普通模式
生产环境清理比FPM更严格：注释里的dd()也可能被解析
FrankenPHP使用Go嵌入PHP运行时，其opcode缓存机制与传统PHP不同。部分版本（尤其是v1.1.0+）在启用opcache.enable_cli=1时，会预扫描所有PHP文件中的函数调用标识——哪怕// dd($secret)这种注释，也可能触发解析器告警或导致worker启动失败。
上线前必须全局搜索并删除：
- 所有
dd(、dump(字面量（含注释、字符串、JSON注释） - Blade中
@dd和@dump指令（不能靠注释掉，得删） - CI/CD流程中加入
grep -r "dd(" . --include="*.php" --include="*.blade.php"校验步骤
最保险的做法：开发阶段用dump()做流程观察，只在确认路径唯一时用dd()，且每次保存前手动删掉。
