Webman日志审计中间件需区分请求/响应、携带用户ID/IP/路由名等上下文、结构化JSON输出且单行，禁用非协程安全句柄、手动控制生命周期、敏感字段脱敏、审计与业务日志物理隔离。
Webman 中间件实现日志审计，不是简单打个 Log::info() 就完事——它必须能区分请求/响应、带上下文（用户ID、IP、路由名）、支持结构化输出，并且不能拖慢高并发吞吐。否则，日志一开，QPS 直接掉 30%。
为什么 Webman 的 LoggingMiddleware 必须手动控制生命周期
Webman 基于 Workerman 常驻内存，中间件实例在进程启动时初始化一次，而非每次请求新建。这意味着：
- 不能在
__construct()里依赖Request或Response——它们尚未生成 - 不能把日志句柄（如
Psr\Log\LoggerInterface）存在属性里并复用，除非确认是线程/协程安全的实现（如Monolog\Handler\StreamHandler默认非协程安全） - 时间戳必须在
process()开始和结束时分别调用microtime(true)，不能用date('Y-m-d H:i:s')——毫秒级耗时统计才有效
process() 里怎么安全提取关键字段
Webman 的 ServerRequestInterface $request 不直接暴露用户身份或路由名，得靠框架层补全。常见做法：
- 用户 ID：从
$request->cookie('user_id')或$request->header('x-user-id')读取，不建议从 session（Webman 默认不内置 session 中间件） - 真实 IP：优先取
$request->header('x-real-ip')， fallback 到$request->getServerParams()['remote_addr'] - 路由名：Webman 的
$request没有原生route()->getName()，需在config/route.php中显式绑定 name，再通过$request->getAttribute('route_name', 'unknown')获取（前提是已启用路由命名中间件） - 请求体大小：用
$request->getBody()->getSize()，但注意大文件上传时 body 可能未加载，此时返回-1
结构化日志写入时的三个硬性约束
企业级审计要求日志可被 ELK / SLS 等系统自动解析，纯文本 print_r() 输出等于白写：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 必须用 JSON 格式输出，且字段名统一（如固定用
event_type而非type或log_type） - 敏感字段如密码、token 必须在写入前脱敏：
preg_replace('/"token":"[^"]+"/', '"token":"***"', $json) - 日志行不能换行 —— 多行 JSON 会被日志采集器切碎；用
JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES保证单行 - 避免使用
file_put_contents()直写文件 —— 并发写会丢日志；应走 PSR-3 兼容的 logger，如Monolog\Logger配合RotatingFileHandler
审计日志和业务日志必须物理隔离
很多团队把审计日志混进 storage/logs/app.log，结果导致：
- 审计字段被业务 log level 过滤掉（比如只保留 warning+，而审计需 info 级）
- 滚动策略冲突：业务日志按天轮转，审计日志需按大小（如 100MB）轮转以满足等保要求
- 权限失控：运维可删业务日志，但审计日志需 WORM（Write Once Read Many）保护
正确做法是单独配置一个 logger 实例，指向独立路径如 storage/logs/audit/，并在中间件中显式调用：$this->auditLogger->info('audit_event', $context)。
真正难的不是写日志，而是让每条日志在 5000 QPS 下仍带完整上下文、不丢、不乱序、不泄露——这些细节没压到中间件里，审计就只是摆设。
