daemonize=1使swoole进程脱离终端并后台运行，需配置log_file和pid_file以保障日志记录与进程管理，否则将导致静默崩溃且无法安全停止。
daemonize=1 后进程彻底脱离终端控制
开启 daemonize => 1 后，Swoole 主进程会执行经典的 double-fork + setsid 流程，使自身与启动它的终端（如 ssh session）完全解耦。这意味着：
- ssh 断开后进程不会收到
SIGHUP，继续运行 - 标准输入（stdin）、标准输出（stdout）、标准错误（stderr）全部被重定向 —— 不再打印到终端
- 进程在系统中表现为独立的 daemon，
ps aux | grep php看不到父 shell 进程树关联 - 若未配置
log_file，所有echo、var_dump、Swoole 内部警告都会被丢弃，/tmp/swoole.log可能成为唯一残留日志位置
为什么必须配 log_file 才能有效调试
daemonize 开启后，PHP 层面的 error_log()、trigger_error() 和 Swoole 自身的运行日志默认都不再可见。不设 log_file 就等于“静默崩溃”。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
log_file是 Swoole 唯一可控的日志落盘路径，只记录 Swoole 内部事件（如 worker 异常退出、reload 失败等） - PHP 错误仍需单独处理：建议在脚本开头加
ini_set('error_log', '/path/to/php-error.log')，并确保display_errors = Off - 目录权限必须提前确认：
/tmp在某些容器或加固系统中不可写，推荐用/var/log/yourapp/并chown www-data:www-data - 日志轮转需自行实现，Swoole 不提供 rotate 功能；可配合 logrotate 或用
file_put_contents($file, $msg, FILE_APPEND | LOCK_EX)手动控制
pid_file 缺失会导致运维操作失效
没有 pid_file，你无法安全地 stop / restart 服务 —— 因为找不到主进程 ID。
-
pid_file必须是绝对路径，且 PHP 进程有写权限；写入时机是 master 进程 fork 完成后、start() 之前 - 常见误操作：
killall php或pkill -f server.php，可能误杀其他 PHP 进程，甚至 manager / task 进程残留 - 正确停止方式是：
kill $(cat /tmp/swoole.pid)，前提是pid_file已写入且未被覆盖或删除 - 若进程异常退出但 pid 文件未清理，下次启动会因文件已存在而失败，需在 start 前加判断逻辑或使用
unlink()清理
daemonize=0 时看似“方便”，实则生产环境不可用
前台运行（daemonize => 0）仅适合本地开发验证流程，上线即出问题。
- 终端关闭、网络中断、IDE 断连都会触发
SIGHUP，导致整个服务退出 - 无法与 systemd / supervisor 集成：这些工具依赖进程 detach 后稳定驻留，前台模式会被判定为“已退出”
- 日志混在终端里，无法统一收集（如对接 ELK、Loki），也难以做容量预估和归档
- 某些云平台（如阿里云函数计算、腾讯云 SCF）明确拒绝前台长期进程，部署直接失败
daemonize，而是忘记配 log_file 和 pid_file —— 这两个字段一旦漏掉，服务就变成“黑盒”，出问题时既看不到错误，也杀不掉进程。
