HTML模板与复杂数据结构组件渲染逻辑

嵌套模板中同名字段（如 mm）如何避免覆盖？

外层和内层 JSON 均包含 mm 字段，若直接顺序替换必然产生冲突——先替换外层后，进入递归时内层 mm 已被替换掉。关键不在于执行顺序，而在于实现作用域隔离。 实际做法是：在递归之前，先提取并暂存所有子结构（即 cc、dd 等 class 名对应的节点）；然后通过正则或 DOM 查询精确定位子模板，再使用 repeatNode 单独处理这些子结构，最后才替换当前层级的字符串键值。这样每个递归调用都只操作自己那一层的 map，mm 不会跨层污染。

• node.querySelector('.cc') 必须存在且唯一，否则 subHtml 插入位置会错乱。
• 替换时使用 subNode.outerHTML.replace(/s/g, ' ') 统一空白符，否则 tmp.replace(subTpl, subHtml) 容易因换行或缩进不匹配而失败。
• 不要在递归前对原始 node 执行 innerHTML 修改，它需要反复用于生成 subTpl。

repeatNode 函数为什么必须接收 DOM 节点而非 HTML 字符串？

只有真实 DOM 节点才能可靠执行 querySelector 和遍历子结构。如果传入字符串，.querySelector('.cc') 会返回 null，后续递归直接崩溃；而使用 document.createElement 解析字符串又会引入额外解析开销和兼容性风险（例如 IE 不支持某些 HTML5 标签）。 实操中常见错误是把模板写成字符串，然后通过 document.createElement('div').innerHTML = template 处理，这会导致 outerHTML 包含多余的 wrapper div，破坏原始结构层级。

• 确保传入的 node 是从文档中取出的真实节点，例如 document.getElementById('test').children[0]。
• arr 参数必须是数组，即使只有一项也要包装成 [map]，否则 for...in 遍历时会把字符串当作字符数组处理。
• 函数返回的是字符串，而非 DOM，因此最终需要赋值给 element.innerHTML，不能直接 appendChild。

深层嵌套时性能瓶颈在哪里？

每层递归都执行一次 outerHTML 字符串拷贝加正则全局替换，复杂度为 O(n)。10 层嵌套加上每层 20 个字段，可能触发浏览器重排卡顿。 真正拖慢进程的不是循环本身，而是字符串拼接和 replace 的重复扫描。尤其当模板中包含大量空白符或注释时，tmp.replace(/s/g, ' ') 这一步反而增加了负担。

• 上线前务必使用 console.time() 测试单次 repeatNode 耗时，超过 16ms（1 帧）就需要优化。
• 可以改用 DOMParser 将模板字符串解析为临时文档，用 cloneNode(true) 复制节点树，再遍历修改 textContent 或 setAttribute，从而避开字符串操作。
• 对静态字段（如 aa、bb）可预编译正则：const re_aa = /{aa}/g，比运行时构造快 3 倍。

为什么不用 innerHTML 直接拼接，而坚持递归 DOM 节点？

因为模板中混用了列表（cc 数组）、键值对（d1、d2）和深层对象（d3 数组中的 x/y），三者的渲染逻辑不同：列表需要循环生成多个副本，键值对是一对一替换，对象则需要递归。硬拼字符串根本无法区分这些语义。 更隐蔽的问题是 XSS 风险——如果 mm 的值包含 ，用 innerHTML 直接插入就会执行；而递归方案至少能控制在文本节点层面做 textContent 设置（虽然当前示例未采用，但架构上保留了可能性）。

• 当前代码用 tmp.replace(re, map[j]) 是最脆弱的环节，生产环境必须添加 escapeHtml(map[j])。
• 模板中 {n} : {v} : {mm} 这种组合式占位符无法被简单正则捕获，实际项目应约定只允许单层 {key}，复杂表达式交给 JS 逻辑预处理。
• 如果数据结构固定，不如使用 template 标签加 content.cloneNode(true)，比手写递归更稳定。

递归渲染的真正难点不在于语法，而在于模板结构与数据结构的耦合深度——多一层 class 嵌套，就多维护一层 DOM 查询路径；少一个字段名约定，整个替换链就会断裂。不要指望一次编写能跑通所有嵌套，先跑通两层，再逐层增加。