webman中高效写入审计日志需异步化：禁用file_put_contents等同步i/o，改用独立进程或事件投递；日志须带trace_id、结构化字段（user_id/ip/action/before/after）并脱敏敏感信息；mysql按月分表+联合索引优化查询。

Webman 中如何高效写入审计日志而不阻塞请求

直接用 file_put_contents 或同步写文件会拖慢接口响应，尤其在高并发审计场景下——这不是性能问题，是架构误用。Webman 默认工作在常驻内存模式，但日志写入仍需避开主线程 I/O。

推荐方案：用 Worker::$processPool 启动独立日志写入进程，或更轻量地使用 Event::on('log.write', ...) 配合 event_add() 投递异步任务。避免在控制器里调用 error_log() 或直接 fopen 写文件。

• 审计日志必须带唯一 trace_id，建议在中间件统一注入到 $request->withAttribute('trace_id', ...)
• 不要用 monolog 的 StreamHandler 默认配置，它默认同步写；改用 RotatingFileHandler 并设置 bubble=false，再配合 BufferHandler 缓冲写入
• 若用 Redis 做日志中转（如先推到 audit:queue list），注意 lpush + brpop 组合比 pub/sub 更可靠，后者在网络抖动时易丢消息

如何结构化存储敏感操作日志（含用户、IP、变更前后快照）

审计不是记录“谁登录了”，而是回答“谁在什么时间、从哪台设备、以什么权限、修改了哪条数据的哪些字段”。这意味着日志体必须是可解析的结构，而不是拼接字符串。

Webman 中建议在业务逻辑层主动构造 $auditLog 数组，而非依赖框架自动捕获。字段至少包含：user_id、ip、ua、action（如 'update_user_email'）、target_id、before 和 after（只存变化字段，不是全量 dump）。

• before/after 必须用 json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)，避免 MySQL 存储时被转义破坏结构
• 敏感字段（如密码、token）必须在进日志前脱敏，推荐统一走 AuditSanitizer::mask($value, $type)，类型包括 'phone'、'id_card'、'email'
• 不要把整个 $request->all() 当日志内容——它可能含上传文件二进制、大图 base64，导致单条日志超 1MB，MySQL 写入失败或 Redis 内存爆掉

MySQL 分表与查询优化：按月分表 + 覆盖索引应对高频审计查询

审计表不是越建越大就越可靠。没做分表和索引优化的 audit_log 表，查一个月内某用户的全部操作，执行计划大概率是全表扫描，500 万行就卡死。

Webman 2.2.0

Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。

下载

Webman 本身不处理 DB 分表，但你得在迁移和模型层主动控制。用 think-orm（Webman 官方推荐 ORM）时，通过 Db::name('audit_log_202409') 动态指定表名，再结合 date('Ym', $timestamp) 计算归属月份。

• 每张分表必须有联合索引：KEY idx_user_time (user_id, created_at)，不能只建 user_id 单列索引
• 禁止在审计表里加 TEXT 字段用于存原始请求体——改用单独的 audit_payload 表，用 audit_log_id 关联，主表只留摘要字段
• 查询时别用 LIKE '%关键词%' 模糊搜操作描述，改用 fulltext 索引或导出到 Elasticsearch，MySQL 原生全文检索对中文支持差且锁表严重

WebSocket 实时推送审计告警时连接频繁断开怎么办

Webman 的 WebSocket Server 在默认配置下，客户端空闲 60 秒就会被踢，而审计告警需要长连接保持——这不是前端心跳没发，是服务端 ws.connection_timeout 和 ws.heartbeat_interval 没调。

在 config/server.php 中调整：'ws' => ['connection_timeout' => 300, 'heartbeat_interval' => 45]。同时，前端必须每 heartbeat_interval - 5 秒发一次 ping 帧（纯字符串 'ping'），服务端收到后回 'pong'，否则连接会被 ConnectionResetError 中断。

• 别在 onMessage 里做耗时操作（如查库、发邮件），审计告警要立刻推，复杂动作扔进 Task 进程异步处理
• 同一用户多端登录时，WebSocket 连接 ID 不等于用户 ID，需在 onOpen 时用 $_SESSION['user_id'] 或 JWT payload 绑定关系，并维护 user_id → [fd1, fd2] 映射数组
• 推送前检查 Connection::isConnected($fd)，避免向已断连的 fd 发送数据，触发 InvalidArgumentException

实际部署时，最常被跳过的一步是审计日志的落盘一致性校验——比如 MySQL 写成功但 Redis 缓存未更新，或 Kafka 生产者返回 success 但 broker 实际没收到。这类问题不会立刻报错，但会让“审计可追溯”变成一句空话。