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 渲染失败
常见踩坑点集中在三类：标签语义错误、样式单位不兼容、事件绑定无效。
<div> 嵌套 <code><p></p>是合法 HTML，但 mp-html 默认把p当块级容器处理，若外层div有display: flex，内部p可能被强制换行——建议统一用div或启用blockTags配置重定义-
style="width: 100%; height: 200px;"没问题，但style="font-size: 14px;"在 iOS 小程序里可能被忽略，必须写成style="font-size: 28rpx;" -
<a href="#" onclick="doSomething()"></a>的onclick不会触发，mp-html 只透传href并绑定tap事件，自定义逻辑得靠组件的bind:linktap回调 - 使用
- 后端渲染：CMS 输出 HTML 时直接插值，最安全，避免 XSS 风险（前提是后端已过滤）
- 前端字符串替换：用
html.replace(/{{([^}]+)}}/g, (_, key) => data[key] || '')，但需注意 HTML 实体转义，比如要先 decode 再替换，否则 <code><div>{{content}}</div>会被当作文本而非标签 - 禁止用
eval或new Function动态执行模板逻辑——mp-html 渲染上下文无全局作用域，且存在严重安全风险 - 如果模板含条件逻辑（如
{{#if hasImage}}<img src="%7B%7Burl%7D%7D">{{/if}}），推荐用轻量模板引擎（如marko或nunjucks）预编译，再喂给 mp-html - 表格优先用 CSS Grid 模拟，mp-html 对
table支持虽全，但每个td都生成独立view，节点爆炸 - 图片必须带
width和height属性，否则 mp-html 无法预占位，导致布局抖动；懒加载默认开启，但首次滚动前仍会触发批量请求 - 避免在模板里写内联
script或style标签——mp-html 会忽略它们，但解析器仍要扫描、跳过，增加 CPU 开销 - 超长段落（>2000 字符）建议按
<p></p>拆分，mp-html 对单个文本节点的渲染优化有限，大文本块容易卡顿
如何让 HTML 模板支持动态数据注入
mp-html 本身不解析模板语法（如 {{title}}），必须在传入前完成替换。关键不是“能不能”，而是“在哪一步做”。
性能瓶颈常出现在 HTML 模板的哪一层
不是解析慢，而是节点深度和图片加载拖垮首屏。实测发现：单页超过 500 个 DOM 节点（尤其嵌套 table > tbody > tr > td）时，微信基础库 2.33.0+ 下渲染耗时从 80ms 跳到 320ms+。
span」——mp-html 不自动清洗，得在传入前用 DOMParser + 自定义规则剥离，否则样式冲突、节点膨胀。
