dom是浏览器接口而非javascript内置部分，根节点为document（nodetype=9），非html；childnodes含所有节点类型，children仅含元素节点；getelementbyid快但id易重复，queryselector更安全灵活；innerhtml会重建dom并丢失事件，textcontent仅改文本且防xss。
DOM 不是 JavaScript 的一部分，而是浏览器提供的接口；你写的 JS 代码能“操作页面”，靠的正是这个树形结构暴露出来的节点对象和方法。不理解它的结构，document.getElementById 和 element.children 就只是死记硬背的 API。
DOM 树的根节点是 document，不是 html
很多人误以为 document.documentElement（即 ）才是根，其实 document 才是真正的根节点。它不对应任何 HTML 标签，但承载了整个文档上下文。
-
document.nodeType === 9（Document 类型），而document.documentElement.nodeType === 1（Element 类型） -
document.body和document.head是快捷属性，本质是document.documentElement的子元素，不是document的直接子节点 - 用
document.childNodes查看，会发现开头可能有文本节点（如 DOCTYPE 前的空白或注释），这会影响遍历逻辑
childNodes 和 children 的区别不只是“带不带文本”
childNodes 返回所有子节点，包括文本节点、注释节点（nodeType === 8）、甚至 IE 下的 CDATA 节点；children 只返回 nodeType === 1 的元素节点——但这个差异在真实项目中会放大成 bug。
- 用
for...of遍历childNodes时，node.textContent可能为null或空格，容易触发未定义行为 -
children是实时集合（HTMLCollection），不包含动态插入的文本节点，适合做 DOM 结构判断（比如 “这个容器有没有子元素？”） - 若需过滤掉空白文本节点，不要手动
filter(n => n.nodeType === 1)，直接用children更可靠
为什么 getElementById 比 querySelector 快，但不能替代它
getElementById 是唯一基于 ID 索引的原生查找，浏览器内部做了哈希优化；而 querySelector 要走 CSS 解析 + 树遍历，开销明显更大。但这不意味着你应该放弃后者。
- ID 在 HTML 中必须唯一，但现实中常有模板重复、SSR 渲染冲突、微前端注入导致 ID 重复——这时
getElementById可能返回意料之外的节点 -
querySelector支持复杂选择器（如[data-id="123"]、.container > .item:first-child），适合组件化场景下局部作用域查找 - 如果只查一次且确定 ID 全局唯一，用
getElementById；否则优先用querySelector，并配合closest向上找父级更安全
innerHTML 和 textContent 修改内容时，副作用完全不同
两者都改内容，但机制天差地别：innerHTML 会触发 HTML 解析、节点重建、事件监听器丢失；textContent 只改文本节点值，无解析开销，也不影响绑定的事件。
- 用
innerHTML = "<span>hello</span>"会销毁原有子节点，重新创建 DOM，已绑定的click事件全部失效 -
textContent对 XSS 安全（自动转义），但无法渲染 HTML 标签；想插富文本又保事件，得用createDocumentFragment+appendChild - 批量更新建议用
document.createDocumentFragment()，避免多次重排重绘；单次更新优先选textContent，除非明确需要解析 HTML
DOM 的“树”不是抽象概念，每个 parentNode、nextSibling 都是真实引用；一旦节点被移出文档，这些引用就断了——这也是为什么动态插入后立即调用 focus() 失败，或者 getBoundingClientRect() 返回 { width: 0 } 的根本原因。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
