webman 生产环境禁用 php://stdout 日志，因其在后台进程下易阻塞主循环、不支持文件锁与日志轮转；应改用 streamhandler 写入具体文件路径，并可为 error/warning 日志额外配置 php://stderr 输出。
Webman 默认把日志往 php://stdout 写，但直接用它会导致线上“假死”、日志错乱、无法归档——这不是配置问题，是流机制本身不适用生产环境。
为什么不能直接用 php://stdout 做日志输出
Linux 后台进程一旦失去控制终端（比如被 systemd、supervisor 管理，或用 & 启动），php://stdout 就可能变成不可写状态。此时 PHP 写入会阻塞，整个 Webman 主循环卡住，表现为 curl 返回 ) Empty reply from server，且无任何错误提示。
另外：php://stdout 不支持文件锁，多 worker 场景下日志行会交叉覆盖；不支持按天切割；无法区分进程来源；终端里也没有颜色高亮。
- 开发时看着方便 ≠ 生产能用
- 哪怕只改
config/log.php里的 handler 路径，不换流类型，照样踩坑 - Webman 是常驻内存框架，不能依赖进程重启来“重开 stdout”
替换 php://stdout 的正确做法：用 StreamHandler 指向真实文件
不是禁用控制台输出，而是把输出目标从“抽象终端流”换成“可持久、可锁定、可轮转”的具体文件路径。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 在
config/log.php中，把原StreamHandler的构造参数从'php://stdout'改成runtime_path().'/logs/console.log' - 确保目录存在：
mkdir -p runtime/logs，并赋予 web 进程写权限 - 如需保留终端实时查看能力，用
tail -f runtime/logs/console.log替代直接看 stdout - 若仍想在开发时看到彩色输出，需额外配
LineFormatter并启用%start%/%end%，且终端支持 ANSI 颜色（大多数现代终端都支持）
如果真要保留控制台输出，必须加保护层
硬要用 php://stdout？至少得防止它崩掉主进程。唯一安全方式是包裹一层异常捕获 + 备用 fallback：
- 自定义一个继承
Monolog\Handler\StreamHandler的类，重写write()方法 - 在
try...catch中执行父类write()，捕获UnexpectedValueException或ErrorException（常见于 stdout 不可用） - 捕获后，自动 fallback 到写入本地文件（如
runtime/logs/stdout_fallback.log），并记录一条 warning：“stdout unavailable, switched to file” - 避免在每次日志写入时都做
is_writable('php://stdout')检查——这个函数本身也可能阻塞
别忽略 stderr 的特殊性
有些部署工具（如 systemd）会把 stderr 单独收集进 journal，而 stdout 被丢弃。如果你的日志全走 stdout，那 journalctl -u your-webman 就看不到任何内容。
更稳妥的做法是：让 ERROR/WARNING 日志走 php://stderr，INFO/DEBUG 走文件。Monolog 支持多个 handler 并存，只需在 channel 配置中加一个 StreamHandler('php://stderr')，并设 level => Logger::WARNING。
注意：php://stderr 同样不支持颜色标记，除非你手动加 ANSI 字符串，且确保接收端（如 journal）不过滤它们。
