feat(mp-review): /mp/review/featured 加 Redis 缓存(PR #869)

这个提交包含在:
API Changelog Bot 2026-04-18 22:16:18 +08:00
父节点 567004c698
当前提交 d7c595ad1f

查看文件

@ -0,0 +1,48 @@
# /mp/review/featured 精选评价接口加 Redis 缓存
**日期**: 2026-04-18
**PR**: #869 → 合并到 dev,已部署测试环境
**Issue**: #867
**影响端**: 小程序 (hl-ui-mp)
**影响接口**:
- `GET /mp/review/featured?limit=N` (公开,精选评价列表)
## 行为变化(对前端透明)
接口响应速度提升:首次请求查库后写缓存,后续 10 分钟内直接命中 Redis。前端无需任何改动。
- **首次请求**:查库 + 写缓存,响应时间与原先一致
- **二次请求**:Redis 命中,响应时间显著下降(预计 <50ms)
- **审核后**:管理员 approve / reject / overrideApprove 任一操作后,精选评价缓存立即失效(事务 afterCommit),下次请求重新落库
## limit 参数归一化
为防止恶意遍历 limit 撑爆缓存 key,MP 层对 limit 做了归一:
| 传入 | 归一后 | 说明 |
|---|---|---|
| null / 不传 | 5 | 默认值 |
| <= 0 | 5 | 非法回落 |
| 1~20 | 原值 | 正常区间 |
| > 20 | 5 | 超出回落 |
**前端注意**:常用 limit 建议固定为 `5``10`,避免在 URL 中频繁变动 limit 造成缓存穿透。
## 不影响
- 返回字段、响应结构、排序规则完全不变
- `MpReviewVO` 字段不变
- 其他 `/mp/review/**` 接口不变
## 实现要点(供前端参考排障)
- Redis Key: `review:featured:limit:{limit}`(仅 limit 为 key 一部分,其他参数不参与缓存)
- TTL: 600s ± 60s 随机抖动;空结果 60s
- 失效触发: `POST /admin/review/{id}/approve` / `.../reject` / `.../override-approve` 审核完成后清缓存
## 已知未修项(另开工单)
1. MP 层 `@MpCache` aspect 泛型反序列化 bug(影响全站,需单独排查)
2. DB `order_review``rating_avg` 复合索引优化(DDL 级)
🤖 Generated with [Claude Code](https://claude.com/claude-code)