上篇钱包分账闭环。这篇写业务闭环的最后一块小拼图评价。它代码量最小但对平台的长期价值可能是最大的——运力质量就是小平台唯一的护城河。评价表设计与防刷约束review 表结构很简单order_id、user_id、driver_id、stars1~5、content、created_time。真正重要的是两条约束1. 只能评价已完成的订单publicvoidsubmit(ReviewReqreq){OrderInfoorderorderMapper.selectById(req.getOrderId());if(!COMPLETED.equals(order.getStatus()))thrownewBizException(只有已完成的订单才能评价);if(!order.getUserId().equals(AuthContext.uid()))thrownewBizException(只能评价自己的订单);// 插入评价}2. 数据库层面加唯一约束兜底UNIQUEKEYuk_order(order_id)-- 一单一评和抢单篇的道理一样应用层校验管体验数据库约束管兜底。并发重复提交、绕过前端直调接口都由唯一索引挡住。司机评分用冗余换体验司机端展示平均分 4.8两种做法每次查AVG(stars) GROUP BY driver_id——实时但每次都聚合driver 表冗余score_total总分和score_count评价数字段评价提交时同一事务累加——查询零成本选后者。评价写入是低频操作读取是高频操作冗余的方向永远应该朝读多写少倾斜。显示时score_total / score_count保留一位小数。订单留痕把 order_log 用成时间线评价做完顺带把订单日志的前端呈现补齐。订单详情页的时间线组件直接由 order_log 驱动09-01 10:32 用户创建订单 09-01 10:35 用户完成支付¥90.00 09-01 11:02 司机[王师傅]抢单成功 09-01 14:20 开始运输 09-01 15:45 运输完成司机入账 ¥81.00平台抽成 10% 09-01 16:10 用户评价★★★★★这一条时间线对三类人都有价值用户看得安心、司机扯皮有据、运营排查有谱。它不需要额外开发——只要从第一天坚持每步落日志第二篇埋的种子这里收获。一个值得讨论的边界要不要允许司机回评用户第一版我的答案是不做双边评价会显著增加复杂度互评可见时机、报复性差评处理而小平台阶段司机是稀缺资源保护司机体验的优先级更高。等产品跑起来、运力饱和了再开——功能延迟决策不是偷懒是排序。本篇成果评价闭环 订单时间线完成业务侧所有功能至此全部收尾。接下来三篇离开小程序写管理后台Vue3 Element Plus 从零搭建、ECharts 数据看板然后是三端联调与上线清单。
