直接 innerhtml 渲染树节点会卡顿，因其需重复解析html、构建dom、计算样式和布局；应改用 + importnode 克隆预定义结构，配合可见性切换与手动同步aria状态，兼顾性能与可访问性。
为什么直接 innerHTML 渲染树节点会卡顿
浏览器每次用 innerHTML 插入一整段树结构 HTML，都要重新解析标签、构建 DOM、计算样式、触发布局——尤其当节点超过 50 个时，主线程明显阻塞，点击下拉框后要等几百毫秒才展开。这不是 JS 逻辑慢，而是 HTML 解析本身成了瓶颈。
常见错误现象：treeContainer.innerHTML = generateTreeHtml(data) 在大数据量下导致输入框失焦、键盘导航延迟、滚动卡顿。
- 避免在循环里反复赋值
innerHTML，哪怕只改一个节点也要重建整棵树 - 不要把
<ul><li>...</li></ul>字符串拼接后一次性插入，浏览器仍需完整解析 - 服务端返回的 HTML 片段若含
<script></script>或未闭合标签，innerHTML会静默失败或错乱
用 + importNode 实现零解析开销渲染
<template></template> 内容天生不参与解析、不执行脚本、不加载资源，只是内存里的静态 DocumentFragment。克隆它比手建 DOM 快 3~5 倍，且结构安全。
实操要点：
- 把树节点结构写死在
<template id="tree-node"><li role="treeitem" data-id="{{id}}">{{label}}</li></template>中，用占位符而非字符串拼接 - 渲染时用
document.importNode(template.content, true)克隆，再用node.querySelector('[data-id]').textContent = label替换内容 - 父子层级靠
appendChild()组装，不是靠字符串嵌套；每层只克隆当前级模板，避免深层递归生成 HTML 字符串 - 首次渲染后缓存克隆结果（如
const cachedFrag = document.importNode(...)），后续展开同级节点直接复用
搜索过滤时别重绘整棵树
本地搜索如果每次输入都调用 renderTree(filteredData)，等于反复走一遍模板克隆+DOM 插入流程，100 个节点时输入法会明显滞后。
更轻量的做法是只切换节点可见性：
- 所有节点初始渲染后统一加
class="tree-node"，搜索时用node.classList.toggle('hidden', !match) - 配合 CSS
.hidden { display: none; }，浏览器跳过布局计算，仅更新渲染树可见性标记 - 匹配不到子节点时，自动折叠父节点（设
aria-expanded="false"并隐藏其<ul></ul>），但不从 DOM 移除 - 远程搜索场景下，
<template></template>仅用于加载新数据块，旧节点保留并复用，避免白屏闪动
ARIA 状态和键盘导航必须手动同步
用 <template></template> 渲染出来的节点默认没有 tabindex、aria-expanded 等状态，屏幕阅读器无法感知展开/选中，方向键也无效。
容易被忽略的细节：
- 每个
<li role="treeitem">必须动态设置tabindex="-1"，首次聚焦时再改为0，否则 Tab 键跳过整个树 - 展开/折叠操作后，不仅要改
aria-expanded，还得同步切换对应<ul></ul>的hidden属性或display样式 - 选中节点时，除了加
aria-selected="true"，还要确保aria-activedescendant指向当前焦点项 ID - 键盘事件监听必须绑定在树容器上（事件委托），而不是每个
<li>单独绑，否则大量节点时内存泄漏风险高
<template></template> 后没手动绑定事件，也没补全 ARIA 状态。看起来能点能搜，但盲人用户完全无法操作，键盘用户按方向键没反应——性能上去了，可访问性却掉了链子。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
