webman可支撑高并发评价系统，但需异步写入（redis队列+批量落库）、模板预热与协程隔离编译、游标分页替代offset、多级缓存（apcu+redis）及主动缓存失效。
Webman 能撑住高并发评价写入和实时展示，但默认配置下很快会卡在数据库写入、模板渲染阻塞和连接数膨胀上——这不是框架不行，而是电商评价场景特有的读写倾斜和瞬时脉冲没被针对性处理。
评价写入别走同步 ORM，先入队再落库
用户点“提交评价”时，如果直接用 Rating::create() 写 MySQL，高峰期几百个并发请求会瞬间打满连接池，连带拖慢整个服务。评价数据本身容忍短时延迟（用户只关心“已提交”，不关心“已入库”），必须异步化。
- 把评价内容、评分、商品 ID、用户 ID 打包成结构化数组，用
Redis LPUSH推入队列（如queue:rating_pending） - 单独起一个常驻进程（
php app/command/ConsumeRatingQueue.php），用BRPOP阻塞消费，批量 INSERT（每 50 条或 100ms 刷一次） - 避免在 WebSocket 或 HTTP 请求上下文中调用
sleep()或usleep()模拟异步——这会阻塞协程，改用Swoole\Coroutine::sleep(0)让出控制权
评价列表渲染必须跳过实时编译，预热 + 协程隔离缓存
商品详情页的“全部评价”区块，若每次请求都触发 view('product/rating')，模板首次加载要解析 AST、生成 PHP 编译文件，多协程并发时会争抢文件锁，CPU 瞬间拉满。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 启动时预编译所有评价相关模板：
php start.php preload:views，遍历resources/view/product/rating.*全部调用view()->make()->render() - 配置
config/view.php中的compiled路径为动态值：runtime/view_compiled/' . md5(\Swoole\Coroutine::getuid())，避免不同协程写冲突 - 禁用生产环境的模板检查：
'auto_reload' => false，否则每次请求都 stat 文件，I/O 开销不可忽视
分页查评价不能用 OFFSET，游标 + 复合索引是硬要求
SELECT * FROM ratings WHERE product_id = ? ORDER BY created_at DESC LIMIT 20 OFFSET 400 这种写法在评价量超 10 万后，OFFSET 越大越慢，MySQL 得扫描前 420 行才取 20 条，接口响应从 20ms 拉到 800ms+。
- 强制要求前端传
cursor参数（比如上一页最后一条的created_at和id组合），SQL 改为：WHERE product_id = ? AND (created_at - 在
ratings表上建联合索引：INDEX idx_product_cursor (product_id, created_at, id)，确保能走索引下推 - 对“最新评价”“最热评价”等不同排序需求，分别建对应索引，不要指望一个索引通吃
用户头像和昵称别实时查，本地缓存 + Redis 双层兜底
每条评价要展示用户头像、昵称，如果每个评价都去查 users 表，100 条评价就是 100 次 DB 查询，哪怕加了连接池也扛不住。用户资料变更频率极低，适合强缓存。
- 首次查询后，把
user_id→['nickname' => 'xxx', 'avatar' => 'xxx']写入Redis HSET user_profile:$user_id，有效期设 7 天 - PHP 层用
apcu_fetch()做本地缓存（单机内存级），命中直接返回；未命中再查 Redis；Redis 也没命中才查 DB，并回填两级缓存 - 用户修改资料时，主动
DEL user_profile:$user_id，而不是等过期——避免脏数据
电商评价系统最难的不是功能实现，而是把“用户感知不到延迟”这件事拆解成可落地的 I/O 调度、缓存策略和 SQL 路径控制。Webman 提供了协程和常驻能力，但具体怎么切、怎么缓、怎么索引，得贴着业务毛细血管去调。
