feat: 接入论坛评论树缓存

docs/backend/计划广场与Token商店后端实施方案.md

@@ -794,14 +794,17 @@ Token 侧：
 
 ### 10.7 缓存策略
 
-P0 不引入复杂缓存，优先靠表结构、索引和分页控制复杂度：
+P0 不引入复杂缓存，但评论区读多写少，评论树需要接短 TTL 缓存：
 
-1. 评论树 P0 不做整树缓存。评论是强互动数据，新增、回复、删除都会影响树结构，缓存失效成本高；当前场景多数用户看完即切，直接查库并组树更简单。
-2. 评论接口按根评论分页，后端读取当前页根评论及其子孙评论后组树，避免一次拉完整帖子全部评论。
-3. 帖子列表和详情 P0 可先不缓存；如果出现热点，再对列表首屏或详情头部做短 TTL 缓存，并在点赞、评论、导入后按帖子维度失效。
-4. 点赞数、评论数、导入数优先存 `forum_posts` 计数字段，写操作事务内增减，避免每次列表都聚合统计。
-5. `token_products` 读取频率高、变化少，可做短 TTL 缓存；但 P0 直接读表也可以接受。
-6. 后续若上 Elasticsearch，只缓存搜索索引，不改变前端接口和论坛业务编排。
+1. 评论树采用 cache-aside + 版本号失效，缓存粒度为 `post_id + sort + page + page_size + version`。版本 key 为 `forum:comments:{post_id}:version`，数据 key 为 `forum:comments:{post_id}:v{version}:sort:{sort}:page:{page}:size:{page_size}`。
+2. 缓存内容是“当前页根评论 + 子孙评论”组装后的去个性化评论树 JSON，并连同分页结果一起缓存；`can_delete` 这类当前用户视角字段不进共享缓存，返回前由 service 按 `actor_user_id` 补齐。
+3. 新增评论、回复或删除评论的 DB 事务成功后，递增 `forum:comments:{post_id}:version`。旧 data key 不扫描删除，依赖短 TTL 自然回收，避免写评论时阻塞 Redis。
+4. Redis 读取、写入或版本递增失败都不影响主链路：读失败直接回源 DB，写失败保持 DB 结果返回，版本递增失败则等待短 TTL 兜底。
+5. 评论接口仍按根评论分页，后端只读取当前页根评论及其子孙评论后组树，避免一次拉完整帖子全部评论。
+6. 帖子列表和详情 P0 可先不缓存；如果出现热点，再对列表首屏或详情头部做短 TTL 缓存，并在点赞、评论、导入后按帖子维度失效。
+7. 点赞数、评论数、导入数优先存 `forum_posts` 计数字段，写操作事务内增减，避免每次列表都聚合统计。
+8. `token_products` 读取频率高、变化少，可做短 TTL 缓存；但 P0 直接读表也可以接受。
+9. 后续若上 Elasticsearch，只缓存搜索索引，不改变前端接口和论坛业务编排。
 
 ### 10.8 联调与验收