应使用 document.getElementById 而非直接用 id 当变量名，因其兼容性差、易冲突、非标准且现代浏览器已弱化；该方法稳定可靠，但需注意大小写敏感、返回 null 及 ID 唯一性。
不能依赖，也不该这么做。
直接用 id 名当变量名是历史遗留行为
某些浏览器（尤其是老版本）会把页面中所有带 id 的元素自动挂到 window 对象上，比如 <div id="myDiv"></div> 之后，你可能在控制台直接敲 myDiv 就拿到这个元素。但这不是标准行为，而是浏览器为兼容上世纪网页做的妥协。
这种机制有明显缺陷：
-
id包含特殊字符（如my-div、1start）时，根本没法当变量名用 - 如果
id和window自身属性重名（比如id="location"），就会被覆盖或冲突 - 现代浏览器（如 Chrome 90+、Firefox 85+）已逐步弱化甚至禁用该特性，尤其在严格模式下直接报错
document.getElementById 是唯一可靠方式
所有主流环境都保证 document.getElementById 的行为一致且稳定。它不关心 id 是否合法变量名，只按字符串精确匹配 DOM 中第一个同名元素。
立即学习“前端免费学习笔记（深入）”；
使用时注意：
-
id值区分大小写：document.getElementById("MyId")找不到id="myid" - 返回值可能是
null，别忘了判空，否则调用.innerHTML会报Cannot read property 'innerHTML' of null - 如果要批量操作多个元素，别硬套
getElementById，改用document.querySelectorAll+ class 或 data 属性
为什么有人还在用直接变量名？
因为旧教程、随手写的调试代码、或者小 demo 里确实“碰巧能跑”。但只要页面稍复杂——比如引入了第三方库、用了 Web Components、或者动态插入元素——这种写法就大概率崩。更隐蔽的问题是：它掩盖了对 DOM 查询机制的理解缺失，导致后续遇到 querySelector、getElementById 返回 null 时完全不知所措。
真正容易被忽略的点是：ID 唯一性约束和查询失败的静默性。哪怕你写了 myElement.innerHTML = "x"，如果 myElement 是靠自动挂载来的，而对应元素被删了或 ID 拼错了，JS 不会立刻报错，而是等到你真去读写属性时才崩，排查成本远高于一开始就写清楚 const myElement = document.getElementById("myId") 并检查是否为 null。
