TypeScript中ChildNode为何允许parentElement与parentNode为null

• 按照TypeScript的DOM类型标注规则，ChildNode类型的实例允许处于无父节点状态：其parentElement和parentNode两个属性的类型定义都包含null选项
• 从命名语义出发，ChildNode字面含义是“子节点”，按理应该天然存在对应父节点；开发者可以理解parentElement可能为null（毕竟父节点可能是非元素类节点，甚至这类场景是否真实存在都存疑），但很难理解为什么parentNode不被设为非空类型
• 查阅DOM规范会发现，规范本身没有对这类场景做明确约束，但“允许无父节点的节点实现ChildNode接口”的设计从语义上确实有违和感
• 有常见推测认为这类设计是为了适配节点从原父节点移出的操作场景，但从逻辑上推导，节点脱离父节点后应该从ChildNode类型转变为普通Node类型，而不是继续保留ChildNode的接口定义

• 首先要明确 ChildNode接口的真实定位：它从来不是用来标记“当前必然依附父节点的子节点”的状态接口，而是用来声明节点“具备作为父节点直接子节点的能力”的能力Mixin——接口本身定义的是remove()、before()、after()这类供“可作为子节点的节点”调用的通用方法，和节点当前是否真的有父节点没有绑定关系。
• 静态类型系统天然无法动态追踪节点的实时状态切换：如果真按“ChildNode必须有父节点”的语义做强类型约束，当节点被执行remove()、脱离DOM树时，TypeScript根本没法在纯静态层面自动把对应变量的类型从ChildNode改为普通Node，既做不到运行时状态和类型的实时同步，还要为了这个语义引入大量无意义的运行时类型校验，反而会大幅拉低开发体验。
• 大量天生无父节点的节点本身就属于ChildNode的适用范围：比如通过document.createElement()刚创建的元素、document.createTextNode()生成的文本节点、空的DocumentFragment，从创建完成的那一刻就具备ChildNode定义的所有方法，但其parentNode天生就是null，从来没有被挂载到任何DOM树中；如果硬把这类节点的parentNode标为非空，类型定义就会直接和运行时真实行为相悖，反而会误导开发者写出存在空指针风险的代码。
• 关于“父节点为非元素类、导致parentElement为null”的场景其实非常常见：比如直接把文本节点挂到document文档节点下，此时该节点的parentNode是Document类型，本身就不属于Element范畴，parentElement自然为null，并非脱离实际的假设场景。
• 所谓“节点脱离父节点后要转变类型”的思路本质上混淆了“能力属性”和“状态属性”的边界：ChildNode是对节点能力的分类，不是对节点当前所处DOM位置的标签。哪怕一个节点已经脱离所有父节点，它依然是那个“可以被插到任意父节点下当子级”的节点，天生就应该保留ChildNode的能力接口，没必要在脱离DOM的时候切掉它本身具备的方法能力。
• 把parentNode标为可空本质上是类型安全性的优先选择：如果为了迁就“ChildNode=子节点”的字面语义硬把parentNode设为非空，类型系统就会对开发者撒谎——明明白白告诉开发者“这个节点一定有父节点”，实际运行时却拿到null，这种为了语义好听牺牲类型真实性的设计，才是真正会给开发者带来麻烦的选择。

内容的提问来源于stack exchange，提问作者Tokimon