refactor: 字典/配置/酒店/活动/景点/餐厅等管理端修改后小程序立即生效

服务: hl-user-service + hl-resource-service + hl-mp-service PR: #894 + #896 Issue: #892 + #893 日期: 2026-04-19 前端是否需要改动: 无需改动（后端行为修复，原调用继续工作且立即可见新数据）

一、背景

继 PR #891 修好轮播图缓存问题后，排查发现项目内还有 6 个 Service 存在相同反模式。本次批量修复让以下对外接口都支持"管理端修改立即生效"：

/admin/dict/type/*、/admin/dict/data/* → /mp/dict/*
/admin/frontend-config/* → /mp/config/*
/admin/hotel/* → /mp/hotel/*
/admin/activity/* → /mp/activity/*
/admin/scenic/* → /mp/scenic/*
/admin/restaurant/* → /mp/restaurant/*

前端可清理的历史 workaround：

保存后刷新页面 / 二次请求 / 延迟拉取
本地"乐观更新"对应数据
"请稍后刷新"类 toast 提示

二、变更接口清单

#	接口组	变更类型	前端改动
1	`/admin/dict/type/` 、 `/admin/dict/data/` CUD	行为修复：保存立即生效	无需
2	`/mp/dict/*`	缓存 TTL 30min → 5min	无需
3	`/admin/frontend-config/*` CUD	行为修复：保存立即生效	无需
4	`/mp/config/*`	缓存 TTL 30min → 5min	无需
5	`/admin/hotel/`、`/admin/activity/`、`/admin/scenic/`、`/admin/restaurant/` CUD 及批量操作	行为修复：保存立即生效；原本批量操作漏清缓存的 bug 也修复	无需
6	`/mp/hotel/`、`/mp/activity/`、`/mp/scenic/`、`/mp/restaurant/`	无变化（TTL 已合理）	无需

请求/响应结构完全不变。

三、修复说明

抽公共工具 CacheEvictAfterCommit，把缓存清理统一推迟到事务提交后
6 个 Service 所有写方法改用这个工具
Dict/Config 过长的读端 TTL 从 30 分钟降到 5 分钟（兜底）
顺带修复 resource 4 个 Service 的 batchUpdateStatus/batchDelete 原本根本没清缓存的 bug

四、前端行动项

无需任何代码改动。可评估清理以下历史 workaround：

可移除的 workaround	原因
字典列表保存后手动刷新	缓存立即失效
配置改完调 `refresh()` 二次拉取	同上
酒店/活动/景点/餐厅列表保存后 setTimeout 重拉	同上
"请稍后刷新"类 toast	可改为"保存成功"

五、测试环境已验证

改 banner title → MP /mp/banner/active 立即返回新值（同一 pattern，其他 Service 沿用）。

2.7 KiB 原始文件 Blame 文件历史 Unescape Escape