树形组件节点编辑需用动态input替代contenteditable：点击进入编辑态，创建input并聚焦，禁用方向键导航；提交或取消后还原DOM、同步数据与ARIA属性，确保语义、焦点流和状态一致性。
树形组件支持节点编辑（如重命名）不是加个 contenteditable 就完事的——它会破坏语义、干扰键盘导航、让屏幕阅读器读出混乱状态，而且和 aria-expanded、tabindex 等关键属性冲突。真正在生产环境跑得稳的编辑方案，必须把“编辑态”当成独立交互阶段来管理。
点击后进入编辑态：用 input 替换文本节点，而非 contenteditable
直接给 <span class="node-label">文件夹A</span> 加 contenteditable="true" 是最常见也最危险的做法。它会让该元素同时具备可聚焦、可编辑、可被屏幕阅读器反复朗读的多重身份，而树形控件的焦点流本就依赖精确的 tabindex 控制。
- 正确做法是：点击节点时，用 JS 动态创建一个
<input type="text">，插入到原位置，focus()并select()全部文字 - 原
span临时移除或aria-hidden="true"，避免辅助技术重复播报 - 编辑完成（Enter/blur/点击其他地方）后，立即销毁
input，还原span，并同步更新数据源和aria-label - 别忘了在
input上监听keydown，对Escape做取消处理（恢复原始值，不提交）
编辑时的焦点与键盘行为必须隔离
树形组件的键盘导航（↑/↓/→/←）和编辑态的输入逻辑天然互斥。一旦进入编辑，方向键应只用于光标移动，不能触发节点切换或展开；Enter 应提交，而非跳转到下一项。
- 进入编辑态后，给
input绑定keydown，对ArrowUp/ArrowDown/ArrowLeft/ArrowRight调用event.preventDefault() - 同时临时解绑树容器上的全局方向键监听，避免事件穿透
- 编辑结束（blur 或 Enter）后，立刻恢复树的键盘导航监听，并将焦点设回当前节点的可聚焦元素（如
button或带tabindex="0"的span） - 如果用户按 Tab 离开编辑框，需判断目标是否仍在树内——否则要手动把焦点收回到树根或上一个有效
treeitem
数据更新与 DOM 同步必须原子化
编辑提交后，仅改 DOM 文本是不够的。树的数据模型、ARIA 属性、甚至父级的子项计数（aria-setsize/aria-posinset）都可能需要刷新。不同层级的节点修改影响范围不同。
立即学习“前端免费学习笔记（深入）”；
- 优先更新内存中的数据对象（如
node.text = newValue），再驱动 DOM 更新，而不是反向操作 - 若节点有子项，确保
aria-expanded和子role="group"的aria-hidden不因编辑被意外重置 - 重命名后，如果该节点是搜索结果高亮项，需重新触发高亮逻辑；如果是懒加载节点，注意不要误触发子节点加载
- 避免在编辑过程中直接操作
innerHTML——XSS 风险高，且会丢失已绑定的事件监听器和data-属性
真正难的不是让文字可改，而是让“可改”这件事不干扰树的语义完整性、键盘流和状态一致性。每次编辑提交，都是对整个树控件状态的一次校验点——漏掉 aria-label 同步、没清理临时 tabindex、忘记重置 aria-posinset，都会在某个辅助技术组合下暴露问题。
