Markdown 转 HTML 转换器

要解决的问题：报告页不是 PPT，却总被当成 PPT 渲染

我们在做的是一个「Markdown → 评审 → 交付」的流水线：LLM 生成的研究报告直接写到 .md，下一阶段由人工或脚本读出，再贴进聊天界面或 Markdown 导出器里。实际交付时遇到两个具体的坑：

• 第一个坑是展示层没有统一的桌面版式。同样是一段分析报告，老板要的是在浏览器里直接看、得上屏演示的页面，不是会把 markdown 原样吐出来的「加载中...」占位符。
• 第二个坑是成本。团队要求单用户最多 100k 次请求里，尽量只有小部分真正投在内容上。现在每份输入都要先跑一次全局 sanitizer（DOMPurify.sanitize），再拼上三个模板文件（head / body / script）后才返回，结果 95% 的请求都是在渲染一个完全空的页壳。

换句话说：我们应该像做前端性能优化一样做模板，而不是每份输入都从零拼一个骨架。

四个可落地的重构

• 用 <template> 做模板缓存，别每次都 document.write

把 head、style、body 外框、footer 脚本抽成 <template id="page-shell">，渲染时 cloneNode 一次。这样一份输入只需要「内容」加上「一段骨架引用」，不会再在 items.md 里冻结掉一次完整嵌套。一句 template.content.cloneNode(true) 就能替换以前几十行拼接代码。

• 把样式从 markdown 头部抽出来

<style> 方块不应该写在每一行 markdown 前面。挪进 <template> 里，页面载入时注入即可。要改配色只需更新模板，所有页面就都跟着变，不必在每个 .md 文件里复制一份。

• 加便宜锚点，而不是引入大脚本

在 h2 前面插入 <a name="sec-id"></a>，纯字符串替换，零依赖。浏览器内置的锚点跳转会打造更好的阅读体验，比写一段 scrollTo 小脚本还稳。

• 流式渲染，先出可用骨架

每收到 40 个 chunk 就 flush 一次完整 <section>，不要等文件结束才一次性输出。同一份输入可以边解析边亮出内容段，体验上就是「打开即有内容」，而不是死等在一个加载态。

适用边界与注意点

• 这不是 Helm chart 替代品。它只负责把模板和内容重组，不负责持久化到数据库，也不做权限映射。需要持久化请另接存储层。
• 模板缓存只在单页上下文中有效；多页应用需要自己管理 <template> 的注册。
• 如果输出会进邮件客户端，谨慎使用 <template>（很多客户端会剥掉它）；那种场景可以回退成 server-side 渲染 + 静态 CSS 文件。