swoole_log_trace无效是因为编译时未启用--enable-swoole-debug或--enable-trace-log；log_level需在start()前设置，且trace/debug等级运行时无效；info到error等级触发场景不同，5.0+默认log_level为warning。
log_level 不是“开/关”开关，而是决定底层哪些调试信号会被采集和输出的过滤器；设错等级或编译缺失支持，日志会静默丢失，连 SWOOLE_LOG_WARNING 都可能不打印。
为什么设了 SWOOLE_LOG_TRACE 却没日志？
因为 SWOOLE_LOG_TRACE 和 SWOOLE_LOG_DEBUG 两种等级在运行时无效，除非编译 Swoole 时显式启用：
-
--enable-swoole-debug或--enable-trace-log缺一不可，仅靠$server->set(['log_level' => SWOOLE_LOG_TRACE])没用 - 线上环境默认编译不含 debug 支持，即使 PHP 扩展已安装，
SWOOLE_LOG_TRACE也会被忽略 - 验证方式：启动后调用
swoole_get_debug_stats()，返回空数组说明 debug 功能未激活
SWOOLE_LOG_INFO 到 SWOOLE_LOG_ERROR 的实际行为差异
这四个等级在所有版本中都可用，但默认行为和触发场景不同：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
SWOOLE_LOG_INFO：只在服务启动、重载、热更新等生命周期事件输出，日常请求不打 -
SWOOLE_LOG_NOTICE：连接关闭、worker 重启、心跳超时等“非错误但需知悉”的事件 -
SWOOLE_LOG_WARNING：DNS 解析失败、SSL 握手异常、协程 yield 超时（如co::sleep(300)被中断） -
SWOOLE_LOG_ERROR：accept 失败、sendfile 出错、内存分配失败等导致功能降级或中断的硬错误
注意：log_level 必须在 Swoole\Server 实例化后、start() 前调用 set() 设置，否则无效。
trace_flags 和 log_level 是两套独立机制
log_level 控制“是否记录”，trace_flags 控制“记录哪部分跟踪细节”，二者必须配合使用才有效：
- 仅设
log_level => SWOOLE_LOG_TRACE但不设trace_flags，底层仍不会输出任何 trace 日志 - 常用组合：
['log_level' => SWOOLE_LOG_TRACE, 'trace_flags' => SWOOLE_TRACE_SERVER | SWOOLE_TRACE_HTTP] -
SWOOLE_TRACE_ALL在高并发下极易刷爆磁盘，建议按需组合，比如只追踪 HTTP 协议解析问题时用SWOOLE_TRACE_HTTP - Docker 环境中若日志写入
/dev/stdout，需确保容器未启用--log-driver=none或 stdout 缓冲未被禁用
最容易被忽略的是：Swoole 5.0+ 废弃了 swoole_error_log 配置项，且 log_level 默认值从 v4.x 的 5（INFO）降到 2（WARNING），升级后不显式设置就看不到 INFO 级日志——这不是 bug，是故意收紧的生产默认策略。
