Webman支撑高并发绩效系统需异步化所有耗时操作：数据库写入走消息队列，Excel导出预生成+URL下载，邮件异步发送，状态统一存Redis并用WATCH/MULTI防重复提交，历史查询强制游标分页与复合索引。
Webman 本身不是为绩效系统而生的框架，但它的常驻内存 + 异步事件模型，确实能撑住高并发、低延迟的考核交互场景——前提是别把它当传统 PHP-FPM 框架用，更不能在 websocket_dispatch 或 HTTP 控制器里直接查库、发邮件、调外部 API。
别在控制器里做耗时操作：HTTP 请求也得异步化
绩效系统常见的“提交自评”“发起360度评估”“批量导出报表”等动作，表面是 HTTP 请求，实际背后可能触发大量 DB 查询、Excel 生成、邮件推送。如果这些逻辑写在控制器里，一次请求卡住，整个 Worker 进程就堵死。
- 所有数据库写入（如保存评分）必须走异步队列，比如用
think-queue或amqp插件投递到 RabbitMQ，Worker 进程只负责入队 - Excel 导出不要用
PhpSpreadsheet在主线程生成——改用预生成 + URL 下载：后台异步写入临时文件，返回/download/20260729123456.xlsx链接，由 Nginx 直接 serve - 邮件通知用
swlib/sw-mail或symfony/mailer+ SMTP 异步发送，千万别用mail()同步阻塞
状态同步别靠内存：Redis 是唯一可信来源
绩效流程中“谁已提交”“谁待评审”“流程是否结束”这类状态，如果只存在 PHP 进程内存里，多实例部署后立刻不一致。Webman 实例重启或扩容，状态全丢。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 用
Redis SETEX存流程节点状态，例如perf:flow:2026Q2:uid_1001:submit，过期时间设为 7 天 - 关键操作加
Redis WATCH/MULTI，避免并发重复提交（比如多人同时点“提交终审”） - 前端轮询状态时，别轮询接口，改用
Redis Pub/Sub推送变更——每个用户订阅perf:user:1001channel，服务端在状态更新后PUBLISH
历史查询必须带游标分页：别碰 OFFSET
绩效数据天然有时间维度，HR 常查“近半年所有部门评分趋势”，SQL 一写成 SELECT * FROM perf_scores ORDER BY created_at DESC LIMIT 50 OFFSET 10000，MySQL 就开始全表扫描，响应从 20ms 涨到 2s+。
- 强制使用复合索引：
ALTER TABLE perf_scores ADD INDEX idx_user_time (user_id, created_at)，查询时按WHERE user_id = ? AND created_at - 分页用游标（cursor），不是页码（page）：上一页最后一条记录的
created_at和id作为下一页参数，避免偏移量累积 - 高频查询结果加缓存：
cache:perf:trend:dept_5:2026Q2，SETEX300 秒，失效后由异步任务重建
WebSocket 仅用于实时通知：别把它当 RPC 用
有人想用 WebSocket 实时传评分、推考核进度，结果把协议设计成类 JSON-RPC，每次消息都带完整业务逻辑解析——这会让连接管理迅速成为瓶颈。
- WebSocket 只干一件事：推送轻量通知，例如
{"type":"review_submitted","target_uid":1002,"flow_id":"2026Q2"} - 具体数据由客户端收到通知后再发 HTTP GET 请求拉取，避免 WebSocket 消息体过大或解析复杂
- 连接数超 3000 后，必须按组织架构分组：用
Redis ZSET存perf:online:dept_5，广播时只推给该部门在线用户，而不是遍历全部连接
真正难的不是让系统跑起来，而是当 HR 突然发起万人级季度考核时，你写的那行 foreach ($users as $u) { $ws->send(...); } 会不会让整个服务卡住 3 秒——这时候 Redis 的原子性、队列的削峰能力、SQL 的索引覆盖，才是决定系统能不能活下来的关键。
