你是前端开发者吗？如果是的话，可能也会大吃一惊。你将发现一个连最资深的工程师都会惊讶的浏览器功能。

隐藏的全局变量技巧

当你给HTML元素设置一个id时，是否知道浏览器会在背后自动创建一个同名的全局JavaScript变量？

比如：

<div id="myElement">Hello World</div>

然后在JavaScript中：

console.log(myElement); // 直接输出这个<div>元素！

不需要document.getElementById()，
也不需要querySelector()，
它就这么直接生效了。

没错，所有主流浏览器至今仍支持这一特性。
为什么这很重要

作为前端技术面试官，我遇到过许多开发者——甚至资深工程师——都从未见过这种行为。它是一个绝佳的“冷知识”面试题，能帮你评估候选人对浏览器底层原理的理解深度。

技术原理解析

这是早期网页开发的遗留特性，源自“浏览器大战”时代，开发者们为了简化操作而添加的快捷方式。

几个关键细节：
仅当id符合JS变量命名规则时生效
（不能有连字符或特殊字符，比如id="my-element"就不行）
不会覆盖作用域内已存在的变量
如果你已经声明了var username，它是安全的，不会被覆盖。
变量会被挂载到全局window对象
即window.myElement === myElement成立。

但最重要的是：
这种将id映射为变量的行为并非现代HTML或ECMAScript标准的一部分
浏览器保留它纯粹是为了兼容旧代码。

“为什么要这样设计？”

当年浏览器开发者的初衷是好的：
“既然用户给元素加了id，他们大概率想在JS里直接用这个名字引用它。”
结果意外制造了一个全局命名空间的灾难。

为什么应该避免使用

即使它能运行，也绝对是个坏实践：
污染全局命名空间
创建难以追踪的隐式引用
缺乏未来兼容性
滥用可能导致调试噩梦

更推荐显式且安全的方式：

const myElement = document.getElementById('myElement');  
// 或  
const myElement = document.querySelector('#myElement');  

清晰、明确、可维护。

面试视角

这是我最爱问的面试题之一：
“如果HTML中有一个id="username"的元素，同时JS中已声明变量var username，会发生什么？”

优秀的程序员会谈到变量作用域、浏览器怪异特性，以及DOM元素如何被附加到window对象。这个问题不是考察死记硬背，而是对浏览器运行机制的理解。

最终思考

作为前端开发者，我们总追逐框架和新工具。但真正的洞见，往往藏在这个平台的诡异边角里——比如这个看似过时却依然存在的全局变量特性。

了解它，理解它，但别用它