daemonize = 1 和 daemonize = true 在 swoole 中逻辑等价，均启用守护进程；但生产环境推荐统一用 1，因部分 php 版本对 true 存在兼容性波动，且官方文档、systemd 模板均采用 1。
daemonize = 1 和 daemonize = true 在 Swoole 中是否等价
等价。Swoole 内部对 daemonize 配置项做布尔类型转换，1、true、"1" 都会被识别为启用守护进程；0、false、null、空字符串则视为禁用。
但生产环境强烈建议统一写 1，原因有二：
-
true在某些 PHP 版本（如 7.4 早期）与 Swoole 扩展的类型校验逻辑存在极少数兼容性波动，虽不报错但可能被静默转为0 - 所有官方文档、示例代码、systemd 单元文件模板均使用
1，保持一致可减少协作和部署时的理解成本
启用 daemonize = 1 后标准输出消失的原因
不是 bug，是 Linux 守护进程的标准行为：调用 fork() + setsid() 后，进程脱离控制终端，stdout / stderr 文件描述符被关闭，后续任何 echo、var_dump、未捕获异常堆栈都会直接丢弃。
必须显式配置日志才能看到运行信息：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
log_file必须设置为绝对路径（如/var/log/swoole-server.log），相对路径在守护后会写入到根目录或失败 -
log_level建议设为0（DEBUG）或2（WARNING），避免默认5（ERROR）漏掉关键启动日志 - 若未配置
log_file，Swoole 会尝试写入/dev/null，但部分容器环境或 SELinux 策略下会静默失败
systemd 管理 Swoole 服务时为什么不能设 daemonize = 1
因为 systemd 本身就是一个进程管理器，它通过 fork 出子进程并监控其生命周期。若 Swoole 再次调用 daemonize = 1，会导致：
- 主进程二次 fork，systemd 失去对真正工作进程的追踪（
ps看不到父子关系，systemctl status显示 inactive 或 failed） - systemd 无法正确发送信号（如
SIGTERM）给 worker 进程，导致systemctl stop超时失败 - pid_file 写入的 PID 可能是中间 fork 出的“幽灵进程”，而非实际提供服务的 master 进程
正确做法是：systemd 场景下 daemonize 必须为 0，由 systemd 自行处理后台化与重启策略。
daemonize = 1 时 pid_file 和 log_file 的路径权限问题
守护进程以当前用户身份运行，但已无终端上下文，因此对路径的访问完全依赖文件系统权限，常见卡点：
-
pid_file目录需对该用户有写权限，否则$server->start()直接抛出failed to write pid file并退出 -
log_file的父目录若不存在，Swoole 不会自动创建（区别于普通 PHP 脚本），需提前mkdir -p /var/log/swoole && chown www-data:www-data /var/log/swoole - 使用
/tmp路径看似方便，但在某些发行版（如 RHEL 8+）中/tmp启用了tmpfiles.d清理机制，PID 文件可能被定时删除
最稳妥的做法是固定使用 /var/run/swoole/（需提前创建并授权），并配合 RuntimeDirectory=swoole 写入 systemd unit 文件。
