API设计：存储HTML类富文本的最佳实践探讨

咱先直接给结论：直接把完整HTML存在后端、通过API返回给WebView展示，本身不算绝对的不良实践——不少成熟CMS（比如WordPress）就是这么玩的，但它确实藏着几个容易踩的坑，得提前留意：

直接存HTML的潜在问题 #

• XSS攻击风险：如果你的富文本允许用户输入（比如用户提交的评论、文章），直接存储和渲染未过滤的HTML简直是给恶意代码开门。比如有人插个<script>偷你用户Cookie()</script>，WebView一渲染就中招了。
• 维护成本爆炸：要是后期想统一改样式——比如把所有h2的字号从18px改成20px——你得批量更新所有存在数据库里的HTML，想想都头大。
• 跨端兼容性坑：不同平台的WebView（比如iOS的WKWebView和Android的系统WebView）对HTML/CSS的支持有差异，你存的HTML可能在一端显示正常，另一端就歪了。
• 数据冗余：HTML标签本身占额外空间，相比轻量级的标记语言，存储和传输效率都更低。

更靠谱的实践方案 #

方案1：用轻量级标记语言（比如Markdown）存储，按需转HTML

• 存储时只存Markdown文本，比如：# 我的标题\n**这是加粗内容**\n![猫主子](https://example.com/cat.jpg)，体积小还好维护。
• 渲染时可以选两种方式：要么后端提前把Markdown转成HTML并缓存（避免重复转换浪费资源），要么前端在WebView里用marked.js这类JS库实时转换。
• 优势：自带安全buff（转换时可以过滤危险标签），样式能通过全局CSS统一控制，编辑也方便——用户用Markdown编辑器输入比写HTML简单多了。

方案2：存储结构化富文本数据（JSON格式）

• 把富文本拆成结构化的JSON数组，比如：

[
  {"type": "heading", "level": 2, "content": "这是二级标题"},
  {"type": "paragraph", "content": ["普通文本", {"type": "bold", "content": "重点内容"}]},
  {"type": "image", "url": "https://example.com/dog.jpg", "alt": "狗主子"}
]

• 渲染时，后端或前端根据这个JSON结构生成对应的HTML（如果是原生APP，甚至可以直接渲染原生组件，不用WebView）。
• 优势：完全可控，样式改起来只需要调整模板，绝对不会有恶意HTML的问题，还能灵活适配不同端的展示需求。

方案3：如果非要存HTML，做好安全过滤和样式解耦

• 必须做严格的XSS过滤：用成熟的库，比如后端用DOMPurify（Node.js、PHP等都有对应实现），只放行安全的标签（比如<h1>-<h6>、<p>、<strong>、<em>、<img>）和属性（比如src、alt）。
• 样式别写进HTML里：把所有样式放在全局CSS文件里，WebView加载HTML时引入这个CSS，HTML只保留结构标签。这样后期改样式只需要更CSS，不用碰数据库里的HTML。

总结 #

如果是简单的富文本需求（比如博客、普通文章），Markdown方案最省心；如果是复杂的富文本（比如带复杂格式的编辑器内容、需要多端适配），结构化JSON方案更灵活；要是你铁了心要用HTML，一定要把安全过滤和样式解耦做好，别给自己埋坑。

内容的提问来源于stack exchange，提问作者lapin