bug: [后端] RenderPostHTML 对含表情包帖子逐实体执行 ResolveURLs 查询，形成 N+1

[HalfAnElephant]

问题概述

rendered_html.go 的 RenderPostHTML 对每个实体调用一次，而该块在每次调用时都执行一次 stickerservice.ResolveURLs DB 查询。由于 ensureRenderedHTML 对任何包含 [:sticker: 的帖子都会绕过版本缓存，一个含 K 个表情包帖子的主题页现在每次请求产生 K 次额外 DB 查询（此前的缓存 HTML 服务不存在该 N+1 模式）。

影响

• 主题页/帖子流渲染性能退化：每个含表情包的帖子 = 1 次额外查询。
• 含表情包的热门主题页在每次请求时都触发，缓存被绕过，放大 DB 压力。

证据

• rendered_html.go:18 — urls, err := stickerservice.ResolveURLs(names) 在 RenderPostHTML 内
• rendered_html.go:49-51 — 含 [:sticker: 时绕过缓存持久化

预期行为

含表情包的帖子也应从缓存服务（或每请求级批处理解析），避免逐实体 N+1 查询。

实际行为

每个含表情包的帖子每次渲染都执行一次独立的 ResolveURLs DB 查询。

建议修复

• 按请求记忆化 name→URL 查找（一次解析整页），或
• 批量解析一次再分发到各实体渲染

来源：OCR review session b0a6067d（HEAD~30..HEAD）medium 级发现。

[oryn-mini]

🧹 Oryn Mini · ✅ Task complete

Code review · Attempt 1 · Cycle 1

Waiting for your decision: 贴纸解析去 N+1 采用哪种方案？
Validation has not run. No repair patch was published by this attempt.

View the Actions run

Run details · operational receipt

{
  "version": 1,
  "workKey": "review:0e35faf9eb83d601948031f0",
  "sourceKey": "0e35faf9eb83d601948031f0",
  "intent": "review",
  "phase": "completed",
  "attempt": 1,
  "cycle": 1,
  "leaseID": "a26e75e1-b6bb-47d4-a0ee-f9c433213472",
  "verdict": "actionable",
  "triage": {
    "category": "bug",
    "priority": "P2",
    "confidence": "high",
    "reproduction": "source_proven",
    "proof": "sufficient",
    "decision": "keep_open",
    "closeReason": "none",
    "canonicalNumber": 706,
    "implementationCandidate": true,
    "complexity": "small",
    "evidence": [
      {
        "path": "apps/gooseforum/app/service/postservice/rendered_html.go",
        "line": 18,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "RenderPostHTML 每次含 token 调用即执行 stickerservice.ResolveURLs，每次调用一条查询。"
      },
      {
        "path": "apps/gooseforum/app/service/postservice/rendered_html.go",
        "line": 49,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "含 [:sticker: 帖子无条件绕过版本缓存，读取时重渲且不持久化；47-48 行注释说明动机是贴纸定义可变。"
      },
      {
        "path": "apps/gooseforum/app/http/controllers/forum/payload.go",
        "line": 1342,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "buildPostPayloads 楼层循环逐层调用 EnsureRenderedHTML，构成页面级查询放大点。"
      },
      {
        "path": "apps/gooseforum/app/models/forum/sticker/sticker_rep.go",
        "line": 56,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "EnabledByNames 每次调用发一条 name IN ? AND is_enabled = ? 的 SQL 查询。"
      },
      {
        "path": "docs/decisions/0030-global-sticker-library.md",
        "line": 47,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "MADR 决策：token 帖每次读取按当前定义重渲、不写回 HTML 缓存；56 行明确记录\"每帖每次读取多一次批量查询\"的 trade-off。"
      },
      {
        "path": "apps/gooseforum/app/service/postservice/rendered_html_test.go",
        "line": 101,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "现有测试断言读路径不得持久化动态贴纸 HTML，是修复必须保持的约束。"
      },
      {
        "path": "apps/gooseforum/app/models/forum/sticker/sticker.go",
        "line": 18,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "stickers.name 为 uniqueIndex，单查是索引 IN 查询，代价在查询次数而非单查耗时。"
      },
      {
        "path": "apps/gooseforum/app/http/controllers/forum/topic.go",
        "line": 434,
        "sha": "3283743586504f0ed7447166305c5ff0d085692f",
        "detail": "修订历史对每条含 token 的可见版本逐条重渲并查询，是楼层循环之外的同类放大点。"
      }
    ],
    "risks": [
      "若以持久化/缓存已展开 HTML 的方式修复，会重新引入管理员改名、停用、删图后历史帖旧图或死链，违反 MADR 0030 与现有测试。",
      "批量解析必须保留失败语义（告警日志 + 保留原始 token），否则 DB 抖动时整页表情渲染行为可能与现状不一致。",
      "实际延迟收益未测量：单查走唯一索引且表小，收益体现在查询次数而非单查耗时；建议用查询计数在 dev 实例验证。"
    ],
    "decisionNote": {
      "question": "贴纸解析去 N+1 采用哪种方案？",
      "options": [
        "每请求批处理解析：全页去重后一次 ResolveURLs，语义与 MADR 0030 完全一致",
        "进程内短 TTL 或管理端写入时失效的 name→URL 缓存，消除读路径查询但引入失效复杂度",
        "两者结合：请求级批处理打底，管理端写入时失效全局缓存"
      ],
      "recommendation": "先做方案 1：改动小、零新鲜度风险；若 dev 实例观测到 stickers 查询仍占显著比例，再考虑方案 3。"
    }
  },
  "run": "https://github.com/YourTongji/YourTJ-Hub/actions/runs/35394616363",
  "summary": "Waiting for your decision: 贴纸解析去 N+1 采用哪种方案？\nValidation has not run. No repair patch was published by this attempt."
}

---

[oryn-mini]

🧹 Oryn Mini · 🧭 Your input is needed

🟡 P2 · Normal · 🐛 Bug · High confidence

What I found

问题成立：按 MADR 0030，含 [:sticker: token 的帖子每次读取都要按当前定义重渲（防止管理员改名/停用/删图后历史帖引用旧图片），而每次重渲各自执行一次表情包名批量查询，于是含 K 个表情包楼层的主题页每次请求多出 K 次小查询，表情包密集的热门页面会把 DB 压力逐层放大。缓存绕过本身是正确性要求、不能回退，正确的修复是把全页 token 名称去重后按请求一次批量解析再分发，而不是让这些帖子回到持久化 HTML 缓存。每条查询都走 stickers.name 唯一索引且表很小，代价主要是查询次数放大而非单次慢查询，属于值得修的 P2。

Proposed change

• Before：ensureRenderedHTML 对每个含 token 帖子在读取时单独调 RenderPostHTML→ResolveURLs，K 层页面 K 次查询；After：payload 构建前收集全页去重后的 token 名称，一次 ResolveURLs 解析，按 name→URL 分发到各楼层渲染。
• Before：RenderPostHTML 内部隐式触发贴纸查询，调用方无法共享结果；After：新增接受预解析查找函数的渲染变体（如 RenderPostHTMLWithResolver），写路径继续用原签名单次调用。
• 保持 MADR 0030 语义：贴纸帖仍每次读取重渲、不写回 HTML 缓存（rendered_html_test.go:101 的不持久化断言必须继续通过）。
• 保持失败语义：批量解析出错时记 slog.Warn 并保留原始 token 文本，渲染输出与现状逐字一致。
• 新增回归测试：多楼层页面渲染只触发一次贴纸批量查询、多楼层共享同一解析结果。

How it fits together

含 [:sticker: 的楼层每次读取重渲，且每层各自触发一次 ResolveURLs 数据库查询，随页面楼层数线性放大。

flowchart TD
  accTitle: 表情包帖子读路径 N+1 查询
  accDescr: 含 [:sticker: 的楼层每次读取重渲，且每层各自触发一次 ResolveURLs 数据库查询，随页面楼层数线性放大。
  n_0["主题页请求"]
  n_1["楼层载荷构建循环"]
  n_2["EnsureRenderedHTML"]
  n_3["贴纸帖缓存绕过"]
  n_4["重渲 RenderPostHTML"]
  n_5["ResolveURLs 数据库查询"]
  n_0 -->|"每请求一次"| n_1
  n_1 -->|"每楼层调用"| n_2
  n_2 -->|"仅含 token 帖"| n_3
  n_3 -->|"每次读取"| n_4
  n_4 -->|"每帖一次 SQL"| n_5

Loading

Review findings

🟡 Medium · 含表情包楼层读路径存在每帖一次的 ResolveURLs 查询放大 — apps/gooseforum/app/service/postservice/rendered_html.go:18

源码证实：RenderPostHTML 每次含 token 的调用都执行一次 EnabledByNames 的 IN 查询；ensureRenderedHTML 对 [:sticker: 帖子无条件绕过版本缓存，因此主题页载荷循环每层调用一次，K 层页面每请求产生 K 次查询。写路径（发帖/编辑/恢复）每次写仅调用一次，不受影响。

🟡 Medium · 缓存绕过是 MADR 0030 有意设计，不能以持久化缓存修复 — apps/gooseforum/app/service/postservice/rendered_html.go:49

绕过缓存是为了防止管理员改名/停用/删图后历史帖出现旧图或死链，注释与现有测试明确禁止读路径持久化动态贴纸 HTML。issue 预期行为若按"从缓存服务"实现会回归该正确性保证；应采用其建议的第二方案（每请求级批处理解析）。

🔵 Low · 楼层循环是主要放大点，其余读路径影响较小 — apps/gooseforum/app/http/controllers/forum/payload.go:1342

buildPostPayloads 楼层循环逐层调用 EnsureRenderedHTML，是放大主体；首帖、回复目标引用与 SEO 首帖每页最多一次。修订历史页也会对每条含 token 的可见版本逐条重渲查询（topic.go:429-435），可在同一修复中顺带覆盖。

More findings (1)

🔵 Low · 同一绕过使 mention 解析随读取重复执行 — apps/gooseforum/app/models/forum/users/users_rep.go:227

含 token 帖子每次读取都重跑完整渲染管线，含 ＠mention 时 GetMentionTargetIds 同样每帖每读一次查询；批处理修复可一并纳入解析，或记录为后续优化。

---

Next step

• cd apps/gooseforum && go test ./app/service/postservice/... ./app/service/stickerservice/... 全绿，尤其不持久化与重渲用例。
• 用 GORM 日志或 PG 语句计数对比修复前后单个主题页请求的 stickers 查询次数（应从 K 降为 1）。
• 确认修复前后生成 HTML 逐字节一致（渲染输出无合同/前端影响，但建议快照比对一次）。
• 若顺带把 docs/decisions/0030 第 47/56 行的 trade-off 措辞从每帖一次改为每请求一次，跑 node scripts/verify-decisions.mjs。

Maintainer decision: 贴纸解析去 N+1 采用哪种方案？

• 每请求批处理解析：全页去重后一次 ResolveURLs，语义与 MADR 0030 完全一致
• 进程内短 TTL 或管理端写入时失效的 name→URL 缓存，消除读路径查询但引入失效复杂度
• 两者结合：请求级批处理打底，管理端写入时失效全局缓存

Recommendation: 先做方案 1：改动小、零新鲜度风险；若 dev 实例观测到 stickers 查询仍占显著比例，再考虑方案 3。

• 实现每请求批量解析：payload 构建前收集并去重全页 sticker 名称，一次 ResolveURLs 后经查找函数传入渲染；修订历史循环同批处理。
• 补回归测试：多楼层渲染仅一次贴纸查询、解析失败保留原始 token、不持久化断言保持通过。
• go vet ./... 与相关包测试通过；MADR 0030 措辞如调整需过 decisions gate。

Things to watch

• 若以持久化/缓存已展开 HTML 的方式修复，会重新引入管理员改名、停用、删图后历史帖旧图或死链，违反 MADR 0030 与现有测试。
• 批量解析必须保留失败语义（告警日志 + 保留原始 token），否则 DB 抖动时整页表情渲染行为可能与现状不一致。
• 实际延迟收益未测量：单查走唯一索引且表小，收益体现在查询次数而非单查耗时；建议用查询计数在 dev 实例验证。

Verification

🔎 Evidence supports the conclusion. Confirmed in source; not reproduced in a live run.

No host validation commands were run for this report.

Source evidence (8)

• apps/gooseforum/app/service/postservice/rendered_html.go:18 — RenderPostHTML 每次含 token 调用即执行 stickerservice.ResolveURLs，每次调用一条查询。

• apps/gooseforum/app/service/postservice/rendered_html.go:49 — 含 [:sticker: 帖子无条件绕过版本缓存，读取时重渲且不持久化；47-48 行注释说明动机是贴纸定义可变。

• apps/gooseforum/app/http/controllers/forum/payload.go:1342 — buildPostPayloads 楼层循环逐层调用 EnsureRenderedHTML，构成页面级查询放大点。

• apps/gooseforum/app/models/forum/sticker/sticker_rep.go:56 — EnabledByNames 每次调用发一条 name IN ? AND is_enabled = ? 的 SQL 查询。

• docs/decisions/0030-global-sticker-library.md:47 — MADR 决策：token 帖每次读取按当前定义重渲、不写回 HTML 缓存；56 行明确记录"每帖每次读取多一次批量查询"的 trade-off。

• apps/gooseforum/app/service/postservice/rendered_html_test.go:101 — 现有测试断言读路径不得持久化动态贴纸 HTML，是修复必须保持的约束。

• apps/gooseforum/app/models/forum/sticker/sticker.go:18 — stickers.name 为 uniqueIndex，单查是索引 IN 查询，代价在查询次数而非单查耗时。

• apps/gooseforum/app/http/controllers/forum/topic.go:434 — 修订历史对每条含 token 的可见版本逐条重渲并查询，是楼层循环之外的同类放大点。

---

Discussion and CI reflect the snapshot read for this review. Current checks and approval are verified separately before merging.

_{🧹 Oryn Mini · Source 3283743 · Built with Synergy core}