导读:评价功能看着简单,真上线就出事:一个订单可以评价十次、评分平均下来全是 4.9 没参考价值、晒图审核不过来。本文给出商城评价系统的落地要点,含可直接复制的表结构与评分聚合逻辑。
评价表最核心的约束是"一个订单商品只能评一次"。结构上拆成评价主表 + 晒图表,晒图单独存,避免图片列表塞爆一行:
CREATE TABLE review (
id BIGINT PRIMARY KEY,
order_item_id BIGINT UNIQUE, -- 订单项,唯一约束防重复评价
product_id BIGINT,
rating TINYINT, -- 1-5
content VARCHAR(500),
status VARCHAR(16) -- pending/approved/rejected
);
CREATE TABLE review_image (
id BIGINT PRIMARY KEY,
review_id BIGINT, image_url VARCHAR(255)
);要点:order_item_id 加唯一约束,重复评价直接报错;评价和订单项关联,只允许已购用户评价(后台校验订单状态)。
一个商品 100 条评价里 90 条 5 分、10 条 1 分,平均 4.6 看似还行,但用户更想知道"多少人给好评、多少人踩雷"。聚合展示用分档占比比单平均数更可信:
// 按评分档位统计占比
function ratingDistribution(reviews) {
const counts = [0, 0, 0, 0, 0]; // 1-5 星
reviews.forEach(r => counts[r.rating - 1]++);
const total = reviews.length || 1;
return counts.map((c, i) => ({ star: i + 1, pct: Math.round(c / total * 100) }));
}要点:列表页同时展示平均分和分档占比(如"5星 90% / 4星 5% / ...");聚合数据要做缓存,评价新增时异步刷新,不要每次请求都全表统计。
晒图是评价里最活跃也最容易被钻空子的地方。流程:用户提交评价+图片 → 图片异步上传 → 管理员审核通过后才对外展示。审核状态字段在评价表里控制:
# 审核流程:提交 -> 审核中 -> 通过/驳回
status: pending -> approved | rejected
# 未通过的评价对外不展示,图片不加载要点:图片上传要限大小和格式(jpg/png、单张 ≤5MB);审核要支持批量操作,高峰期别让审核积压;被驳回的评价可以给一次修改机会,不要直接删用户数据。
评价刷屏、恶意差评是商城运营的常态问题。基础防线三道:未购买不能评(校验订单)、同一订单项只能评一次(唯一约束)、单位时间评价次数限流:
# 评价接口风控
IF 订单项不存在 OR 已评价 THEN 拦截;
IF 该用户近1小时评价数 > 10 THEN 拦截;
IF 评价内容含敏感词 THEN 进人工审核;要点:评价频率限流按用户维度做(Redis 计数),防止机器刷;敏感词过滤不能只挡词,还要配合人工审核兜底;评价删除要走软删除,防止用户反复操作。
评价系统按「结构约束 → 分档聚合 → 先审后上 → 三重风控」落地,库表卡住重复、聚合给出真相、审核管住内容、风控挡住刷屏,四件事缺一不可。同类分层在乔拓云商城的评价管理模块中有对应实现,中小电商可直接参照该模块的评价结构与审核流程起步。
评价是商城的信任资产:约束防重复、分档给真相、审核守底线、风控挡刷屏。结构先立规矩,聚合再给参考,审核和风控托底,评价墙才能既热闹又可信。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。