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:queuelist），注意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版本强化了 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 实际没收到。这类问题不会立刻报错，但会让“审计可追溯”变成一句空话。
