dom中没有node.type和node.name，正确属性是nodetype（只读数值，标识节点本质类型）和nodename（按类型映射的字符串名称，如"div"、"#text"），二者共同构成dom节点继承体系的基础识别机制。
直接说结论：DOM 中没有 node.type 和 node.name 这两个属性——正确写法是 nodeType 和 nodeName。它们不是“类型判断的快捷方式”，而是理解整个 DOM 节点继承体系的关键入口。
nodeType 是识别节点本质的数字身份证
所有节点都继承自 Node 接口，而 nodeType 就是这个接口定义的只读数值属性，它不随浏览器变化，也不依赖标签名或内容，纯粹反映节点在 DOM 规范中的根本身份。
-
document.nodeType === 9→ 表示它是文档根节点（Node.DOCUMENT_NODE） -
div.nodeType === 1→ 表示它是元素节点（Node.ELEMENT_NODE），哪怕你用document.createElement('svg')创建，值仍是1 -
textNode.nodeType === 3→ 表示它是纯文本容器（Node.TEXT_NODE），和是否包含空格、换行无关
这种设计让类型判断既轻量又可靠。比起用 instanceof Element（IE 不支持 Node 构造函数），用 node.nodeType === 1 兼容性更好、语义更清晰。
nodeName 是跨节点类型的统一名称协议
nodeName 不是“取标签名”的别名，而是按节点类型严格映射的字符串标识符，它揭示了不同子类如何共用同一套命名规则：
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 元素节点（
Element）→ 返回大写标签名：<div> → <code>"DIV"；<custom-el></custom-el>→"CUSTOM-EL" - 文本节点（
Text）→ 固定为"#text"，不暴露内容，只表明“我是一个文本载体” - 注释节点（
Comment）→ 固定为"#comment"，和 HTML 中<!-- ... -->一一对应 - 文档节点（
Document）→ 固定为"#document"，是整棵树的逻辑起点 - 当你拿到一个节点，先查
nodeType确认它属于哪一大类（如1= 元素，3= 文本） - 再看
nodeName，确认它在该大类下的具体角色（如"DIV"或"#text"） - 此时可安全调用对应方法：元素节点可用
getAttribute()，文本节点可用nodeValue，而nodeType !== 2时访问ownerElement就会是undefined
注意：tagName 只存在于元素节点，而 nodeName 存在于所有节点——这正体现了 Node 是基类、Element 是其子类的继承关系。
结合使用才能看清继承链的真实结构
单看一个属性容易误解，但把 nodeType 和 nodeName 并列观察，就能还原出 DOM 类型系统的骨架：
例如：document.body.firstChild 很可能是空白文本节点（nodeType === 3, nodeName === "#text"），而非你预期的 <h1></h1> ——这恰恰说明 DOM 树真实包含所有字符级节点，不是“HTML 字符串的简化映射”。
为什么不用 instanceof 判断节点类型？
因为 Node 在旧版 IE 中不可构造，Element 和 Text 也非标准全局类。而 nodeType 和 nodeName 是所有浏览器从 DOM Level 1 就稳定支持的底层属性，它们不依赖 JS 运行时类系统，只依赖 DOM 规范本身。换句话说：它们是 DOM 的“汇编指令”，而 instanceof 是“高级语言语法”——前者更接近底层继承关系的本质。
