fix(user,mp): 轮播图修改后小程序立即生效（修缓存不清导致最长 30min 延迟）

服务: hl-user-service + hl-mp-service PR: #891 Issue: #888 Merge commit: 已合并到 dev 日期: 2026-04-19 影响范围: 管理端修改轮播图后小程序实时性 前端是否需要改动: 无需改动（后端行为修复，前端原调用继续工作且立即可见新数据）

一、背景

管理端 PUT /admin/banner/{id} 修改轮播图保存成功后，小程序端 GET /mp/banner/active 仍返回旧数据，最长 30 分钟才自动更新。

前端影响：如果之前前端有以下 workaround，现在可以移除：

强制刷新页面、二次请求、轮询轮播图接口
"保存后等一会儿"的用户提示

二、变更接口

#	接口	方法	路径	变更类型	前端改动
1	新建/修改/删除轮播图	POST/PUT/DELETE	`/admin/banner` `/admin/banner/{id}`	行为修复：保存立即生效	无需
2	小程序轮播图列表	GET	`/mp/banner/active`	缓存 TTL 由 30min 降到 5min	无需

两个接口的请求/响应结构完全不变。

三、修复说明

两层原因叠加导致 bug：

代码层：BannerService.create/update/delete 在 @Transactional 事务体内调用缓存清理，事务提交前存在时间窗口，并发读请求把旧数据写回 mp:banner:active 开启新 30min TTL
配置层：测试环境 Nacos 把 hl-mp-service-test.yml 的 redis.database 配成 1，而 user/resource 服务未显式配置（默认 DB 0），跨 DB 导致 MpCacheEvict 一直清不到 mp 缓存

已修：

代码：evict 移到 TransactionSynchronization.afterCommit() 回调；TTL 30min → 5min（兜底）
配置：Nacos hl-mp-service-test.yml 的 redis.database: 1 改为 0，与其他服务对齐

四、前端行动项

无需任何改动。清理历史 workaround 的列表：

可移除的 workaround	原因
保存轮播图后调用 `refresh()` / 延迟 2 秒重拉	后端已立即清缓存
本地存储一份"乐观更新"轮播图	不再必要
"请稍后刷新"类 toast 提示	可改为"保存成功"

五、测试环境已验证

端到端实测（2026-04-19 01:35）：

# 步骤 1：PUT banner/5 title="嗨冰雪" → code=200
# 步骤 2：GET /mp/banner/active → "嗨冰雪" ✓
# 步骤 3：PUT banner/5 title="嗨冰雪(V2验证)" → code=200
# 步骤 4：GET /mp/banner/active → "嗨冰雪(V2验证)" ✓ 立即生效
# 步骤 5：PUT 回滚 title="嗨冰雪" → code=200
# 步骤 6：GET /mp/banner/active → "嗨冰雪" ✓

后端团队下一步计划：同类"事务内清缓存 + 跨 DB"隐患还存在于 SysDict/FrontendConfig/Hotel/Activity/Scenic/Restaurant 6 个 Service，将以批量 PR 统一抽 CacheEvictAfterCommit 公共工具类解决。前端同样无需改动。

3.0 KiB 原始文件 永久链接 Blame 文件历史 Unescape Escape