HTML 元素设置 id 属性后，其值会作为“命名属性”（named property）自动暴露在 window 对象上，但该属性并非 window 自身的自有属性（own property），而是存在于 window 的命名属性对象（named properties object）中——这是一个 WebIDL 规范定义的特殊原型链节点，不可枚举、不参与 Reflect.ownKeys() 或 for...in 遍历。
html 元素设置 `id` 属性后，其值会作为“命名属性”（named property）自动暴露在 `window` 对象上，但该属性并非 `window` 自身的自有属性（own property），而是存在于 `window` 的命名属性对象（named properties object）中——这是一个 webidl 规范定义的特殊原型链节点，不可枚举、不参与 `reflect.ownkeys()` 或 `for...in` 遍历。
在 HTML 中，为任意元素添加 id 属性（如
），不仅便于 CSS 选择器和 document.getElementById() 定位，还会触发浏览器的命名属性暴露机制（named property exposure）。这一行为由 HTML Living Standard 明确规定：所有拥有有效 id 的元素，其 id 值必须作为命名属性，在 window 对象上可访问（例如 window.header 或直接 header）。但关键在于：这不是常规的 JavaScript 属性赋值。它不通过 window.id = element 实现，也不将属性写入 window 对象自身（即非 Object.prototype.hasOwnProperty.call(window, 'id') === true 的“自有属性”）。相反，规范要求该属性必须暴露在 window 的命名属性对象（named properties object）上——这是一个位于 window.__proto__.__proto__（即 Window.prototype.__proto__）之上的、由引擎内部管理的特殊原型对象。
该对象是一个 WebIDL 定义的exotic object（奇异对象），其核心特征包括：
- ✅ 支持 in 操作符和点号/方括号访问（'a' in window、window.a 返回元素）；
- ✅ hasOwnProperty() 返回 true（因 WebIDL 规范重写了 [[HasProperty]] 内部方法）；
- ❌ 不参与枚举：Reflect.ownKeys(window)、Object.keys(window)、for...in 均无法列出这些 id；
- ❌ 无 [[OwnPropertyKeys]] 自定义实现：其内部方法仍沿用 OrdinaryOwnPropertyKeys，仅返回真实自有属性（如 window.console、window.location 等），而命名属性被刻意排除；
- ⚠️ 同名全局变量会被覆盖：若同时声明 var a = 'override';，则 window.a 将指向该变量而非 DOM 元素（优先级：显式声明 > 命名属性）。
以下代码直观验证该机制：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
<!DOCTYPE html>
<html>
<body>
<div id="testEl">Hello World</div>
<script>
console.log('testEl' in window); // true —— 可访问
console.log(window.testEl); // <div id="testEl">...
console.log(window.hasOwnProperty('testEl')); // true —— 但注意：这是 WebIDL 语义的“拥有”，非 JS 原生语义
console.log(Reflect.ownKeys(window).includes('testEl')); // false —— 不可枚举
console.log(Object.getOwnPropertyNames(window).includes('testEl')); // false
// 验证命名属性对象位置（仅作探究，生产环境勿依赖）
const proto2 = Object.getPrototypeOf(Object.getPrototypeOf(window));
console.log(proto2); // 如 Chrome 中为 WindowProperties {}
console.log(Reflect.ownKeys(proto2)); // 通常为空或仅含 Symbol 键，不包含 'testEl'
</script>
</body>
</html>⚠️ 重要提醒与最佳实践：
- 禁止依赖此机制：该行为属于历史遗留特性（源于早期 Netscape），现代标准已明确标注为 “should be avoided in new code”；
- 命名冲突高危：id="location" 会覆盖 window.location，id="name" 可能干扰 window.name，导致静默故障；
- SSR/测试环境失效：服务端渲染或 JSDOM 环境中，该机制通常不启用，造成行为不一致；
- 替代方案明确：始终使用 document.getElementById('xxx') 或 document.querySelector('#xxx')，语义清晰、跨环境可靠、类型安全（配合 TypeScript 更佳）。
综上，id 挂载的本质是 WebIDL 层面的协议约定，而非 JavaScript 属性模型的自然延伸。理解其“存在但不可见”的特性，有助于规避陷阱，并坚定采用标准化 DOM 查询方式——这才是健壮前端工程的基石。
