workerman 后台运行时必须配置日志路径，否则 echo、异常等全部丢失；推荐设置 $worker->logfile 指定可写路径，或启动时重定向 stdout/stderr，需避坑如目录存在、权限正确、避免 /tmp 丢失日志。
Workerman 在 Linux 下用 -d 参数后台运行时，默认不会输出日志到终端，所有 echo、var_dump 或异常堆栈都会被丢弃。要让日志可查、可追踪，必须主动配置日志路径——这不是可选项，而是生产环境的强制要求。
守护进程模式下日志不显示的原因
启用 -d 后，Workerman 会调用 setsid() 脱离终端会话，并重定向标准输出（stdout）和标准错误（stderr）到 /dev/null。这意味着：
- 你在代码里写的
echo "start"或error_log("xxx")全部静默消失 - PHP 错误、未捕获异常、Worker 启动失败等关键信息无法被看到
- 排查问题时只能靠猜，或临时切回前台模式（但生产环境不允许）
正确配置日志输出的两种方式
推荐优先使用 Workerman 原生日志机制，它比 PHP 的 error_log 更稳定、可定制性强：
- 在启动脚本顶部引入日志类：
use Workerman\Worker;并确保已加载 Autoloader - 为每个 Worker 实例设置
$worker->logFile = '/path/to/your/app.log'; - 日志路径需保证运行用户（如 www-data）有写权限，且目录存在
- 若需区分 HTTP/WS/自定义协议日志，可为不同 Worker 指定不同文件，例如：
http_worker.log、ws_worker.log
如果只是临时调试，也可在启动命令中重定向 stdout/stderr：
php start.php start -d >> /var/log/myapp.log 2>&1- 注意：该方式无法按 Worker 实例分离日志，也不支持自动轮转，仅适合短期验证
避免日志配置失效的常见坑
即使写了 logFile，日志仍为空？检查以下几点：
- 路径中的父目录必须已存在，Workerman 不会自动创建多级目录
- 确认运行用户（如执行
ps aux | grep php查看）对日志路径有写权限 - 不要把日志写到
/tmp下且未加清理策略——某些系统重启后清空 tmp，导致日志丢失 - 若用 systemd 管理服务，
StandardOutput=journal和StandardError=journal可将输出导入 journalctl，但需额外配置LogRotate
日志不是锦上添花，而是守护进程能被信任的前提。配好 logFile，再加个简单定时任务压缩旧日志，就基本稳了。
