DOM节点操作是需兼顾准确性、可维护性与性能的闭环流程：先精准定位节点，再安全执行增删改查，最后通过缓存、批量、脱离文档流等手段抑制回流重绘。
dom 节点操作不是“查完就改、改完就走”的线性动作，而是一个需兼顾准确性、可维护性与性能的闭环流程：先精准定位节点，再安全执行增删改查，最后通过缓存、批量、脱离文档流等手段抑制回流重绘。真正影响体验的，往往不是单次操作，而是重复查询、零散修改和未收敛的副作用。
节点定位：选对方法，避免实时集合陷阱
获取节点是所有操作的起点，但不同 API 行为差异显著：
-
有 ID 就用
getElementById—— 性能最高，返回单个元素，无歧义； -
需要灵活性时优先
querySelector/querySelectorAll—— 返回静态 NodeList，遍历时不会因 DOM 变动导致漏项或死循环； -
慎用
getElementsByClassName或getElementsByTagName—— 它们返回的是“实时集合”，在循环中移除类名或插入新元素会动态改变长度，极易出错； - 所有查询结果建议缓存到变量中 —— 尤其在事件回调或高频函数里，避免每次调用都重新遍历整棵 DOM 树。
节点增删改：用对 API，减少渲染开销
操作本身不慢，触发浏览器重排重绘才慢。关键在于“怎么改”：
-
批量添加多个子节点，用
DocumentFragment—— 先把所有新节点 append 到 fragment，再一次性插入父容器，只触发一次回流； -
修改样式优先切换 class，而非逐个设
style.xxx—— 单次 class 变更由 CSS 引擎统一计算，比多次内联样式赋值更高效； -
更新文本内容用
textContent，不用innerHTML—— 后者会触发 HTML 解析、DOM 重建，还存在 XSS 风险； -
删除节点前，若后续还有大量操作，可先设
display: none—— 让它暂时脱离渲染树，避免中间状态反复重排。
节点关系与类型判断：明确语义，避免误操作
DOM 节点类型多样，混用容易引发静默错误：
-
区分
childNodes和children—— 前者包含文本、注释等所有节点，后者只含元素节点，遍历时注意过滤； -
判断节点类型用
node.nodeType—— 如Node.ELEMENT_NODE === 1、Node.TEXT_NODE === 3，比靠 tagName 或 textContent 推断更可靠； -
找父级时注意
parentNode与parentElement区别 —— 前者可能返回 document 或 documentFragment，后者只返回 Element 类型，避免后续调用 classList 报错； -
检查是否包含某节点用
parent.contains(child)—— 比递归比对 parentNode 更简洁安全。
性能兜底：从设计阶段就规避高频代价
优化不是补救，而是前置约束：
立即学习“Java免费学习笔记（深入）”；
- 把 DOM 操作从循环体中剥离 —— 比如遍历数组生成列表，先拼好 fragment 或字符串，再一次性挂载；
-
事件绑定用委托代替遍历注册 —— 尤其对动态生成或数量不确定的子元素，监听父容器 +
event.target.matches()更轻量； - 避免在 scroll、resize 等高频事件中直接操作 DOM —— 加节流（throttle）或使用 IntersectionObserver 替代滚动监听；
-
克隆节点时留意
cloneNode(true)的深度影响 —— 若只复制结构不含事件和表单状态，用false更省资源。
DOM 操作本身很简单，难的是在功能、可读和性能之间找到平衡点。每一次 querySelector、每一次 appendChild，背后都有浏览器渲染管线在响应。写得快不如写得稳，改得勤不如改得准。
