mp-html更适合模板化渲染，因其直接解析HTML字符串为原生组件树，支持table、video及rpx单位，而rich-text仅支持极简HTML且需手动节点映射；常见失败原因包括p标签嵌套错位、font-size未用rpx、onclick无效及非标准空格实体。

mp-html 为什么比原生 rich-text 更适合模板化渲染

因为 mp-html 把 HTML 字符串当作输入源，直接解析成小程序原生组件树，而原生 rich-text 只能接受 nodes 数组或极简 HTML（如不支持 table、video、内联 style 中的 rpx 单位）。如果你手写 HTML 模板（比如 CMS 输出的带样式文章），mp-html 能 1:1 渲染；rich-text 则必须先用 JS 做一遍 DOM 解析 + 节点映射，成本高、易出错。

HTML 模板里哪些写法会让 mp-html 渲染失败

常见踩坑点集中在三类：标签语义错误、样式单位不兼容、事件绑定无效。

• 嵌套

  是合法 HTML，但 mp-html 默认把 p 当块级容器处理，若外层 div 有 display: flex，内部 p 可能被强制换行——建议统一用 div 或启用 blockTags 配置重定义
• style="width: 100%; height: 200px;" 没问题，但 style="font-size: 14px;" 在 iOS 小程序里可能被忽略，必须写成 style="font-size: 28rpx;"
• 的 onclick 不会触发，mp-html 只透传 href 并绑定 tap 事件，自定义逻辑得靠组件的 bind:linktap 回调
• 使用   替代空格没问题，但   或   不被解析，会原样显示为文字

如何让 HTML 模板支持动态数据注入

mp-html 本身不解析模板语法（如 {{title}}），必须在传入前完成替换。关键不是“能不能”，而是“在哪一步做”。


Wechat Article Html
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
下载
• 后端渲染：CMS 输出 HTML 时直接插值，最安全，避免 XSS 风险（前提是后端已过滤）
• 前端字符串替换：用 html.replace(/{{([^}]+)}}/g, (_, key) => data[key] || '')，但需注意 HTML 实体转义，比如 要先 decode 再替换，否则
  {{content}}
  会被当作文本而非标签
• 禁止用 eval 或 new Function 动态执行模板逻辑——mp-html 渲染上下文无全局作用域，且存在严重安全风险
• 如果模板含条件逻辑（如 {{#if hasImage}}{{/if}}），推荐用轻量模板引擎（如 marko 或 nunjucks）预编译，再喂给 mp-html

性能瓶颈常出现在 HTML 模板的哪一层

不是解析慢，而是节点深度和图片加载拖垮首屏。实测发现：单页超过 500 个 DOM 节点（尤其嵌套 table > tbody > tr > td）时，微信基础库 2.33.0+ 下渲染耗时从 80ms 跳到 320ms+。

• 表格优先用 CSS Grid 模拟，mp-html 对 table 支持虽全，但每个 td 都生成独立 view，节点爆炸
• 图片必须带 width 和 height 属性，否则 mp-html 无法预占位，导致布局抖动；懒加载默认开启，但首次滚动前仍会触发批量请求
• 避免在模板里写内联 script 或 style 标签——mp-html 会忽略它们，但解析器仍要扫描、跳过，增加 CPU 开销
• 超长段落（>2000 字符）建议按
  拆分，mp-html 对单个文本节点的渲染优化有限，大文本块容易卡顿

真实项目里，最难处理的不是模板语法或标签兼容性，而是「后端返回的 HTML 里混着 Word 导出的冗余 class 和嵌套 span」——mp-html 不自动清洗，得在传入前用 DOMParser + 自定义规则剥离，否则样式冲突、节点膨胀。