# /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)