Worker::$logFile 设置的是 Worker::log() 方法输出的业务日志，仅限绝对路径且需PHP进程有写权限；PHP错误日志由 php.ini 的 error_log 控制；stdout 输出由 Worker::$stdoutFile 管理；master 进程日志默认在启动脚本同级目录。
Worker::$logFile 设置的是什么日志？
它只控制 Worker::log() 调用输出的内容，比如你在 onMessage 里写了 Worker::log('received')，这条才会进这个文件。不是 PHP 错误、不是 echo、也不是未捕获异常——这些都不归它管。
这个路径必须是绝对路径，且 PHP 进程有写权限。常见错误是填了 ./logs/workerman.log 或 logs/workerman.log，守护进程下工作目录可能已变，直接写失败。
- 正确写法：
Worker::$logFile = '/var/log/workerman/app.log'; - 提前创建目录：
mkdir -p /var/log/workerman并chown www-data:www-data /var/log/workerman - 别指望它自动建目录或自动轮转，写满磁盘也不会停
PHP 错误日志（Fatal Error/Warning）去哪了？
Workerman 进程里抛出的致命错误、禁用函数调用失败、扩展崩溃等，走的是 PHP 原生错误通道，由 php.ini 的 error_log 和 log_errors 控制，和 Worker::$logFile 完全无关。
- 查当前生效的配置：
php --ini找 CLI 模式的php.ini，再grep -E '^(error_log|log_errors)' /path/to/php.ini - 确保
log_errors = On，且error_log = /var/log/php_errors.log（路径需可写） - 如果用了
disable_functions，重点检查pcntl_fork、posix_kill是否被禁——它们一被禁，master 就可能直接退出，连错误都来不及记
为什么 php start.php start -d 后看不到任何日志？
因为守护进程模式下，默认把所有 echo、var_dump、print_r 都重定向到 /dev/null，除非你显式设置了 Worker::$stdoutFile。
-
Worker::$stdoutFile是专门收这些“终端输出”的，和Worker::$logFile分开管理 - 设成
Worker::$stdoutFile = '/var/log/workerman/stdout.log';后，所有echo "hello"都会落盘 - 注意：它不记录 PHP 错误，也不记录
Worker::log()，三者互不干扰 - 调试阶段建议同时开：
ini_set('display_errors', 'on'); error_reporting(E_ALL);，否则 warning 级别错误直接静默
master 进程自己的日志在哪？
Workerman master 进程（管理 worker 的那个）会把自身状态变化写进一个独立日志，默认叫 workerman.log，位置在启动脚本同级目录，比如你运行 php start.php start -d，日志就在 start.php 所在目录下。
这个文件里能看到 “worker[3] exit with status 256”、“reload success”、“stop all workers” 这类框架级事件，是排查进程意外退出的第一手资料。
- 想改位置？只能靠启动时重定向：
nohup php start.php start -d >> /var/log/workerman/master.log 2>&1 & - 别依赖它查业务逻辑问题——它不管你的
onMessage有没有执行，只管自己有没有崩 - 如果发现日志为空，先
ps aux | grep start.php确认 master 进程是否真在跑
实际部署中，Worker::$logFile、Worker::$stdoutFile、PHP error_log、master 默认 workerman.log 这四条线经常混在一起看，但它们源头不同、开关独立、权限要求也不同。漏配任意一条，都可能让关键线索彻底消失。
