我使用过的所有浏览器都允许id="myDiv"通过简单地编写来访问元素：
myDiv
见这里：http : //jsfiddle.net/L91q54Lt/
无论如何，这种方法似乎没有很好的记录，事实上，我遇到的消息来源甚至没有提到它，而是假设人们会使用
document.getElementById("myDiv")
或许
document.querySelector("#myDiv")
访问一个 DOM 元素，即使它的 ID 是预先知道的（即不是在运行时计算的）。我可以说，如果有人无意中尝试myDiv在更广泛的范围内重新定义（虽然这不是一个绝妙的主意......），后一种方法具有保持代码安全的优点，用一些不同的值覆盖它并且在没有注意到冲突的情况下继续进行.
但除此之外呢？除了代码设计之外，使用上面的简短形式是否有任何问题，或者我在这里还缺少什么？
无论如何，这种方法似乎没有很好的记录，事实上，我遇到的消息来源甚至没有提到 [...]
除了依赖隐式声明的全局变量之外，缺乏文档是不使用它的一个重要原因。
将id值明显提升为全局变量不符合标准（ID 属性的HTML5 规范没有提到它），因此，您不应该假设未来的浏览器会实现它。
编辑：原来，这种行为是符合标准-在HTML5中，window应该支持“命名元素”访问属性：
出于上述算法的目的，具有名称 name 的命名对象是那些：
- 名称为name的活动文档的子浏览上下文，
- a、applet、area、embed、form、frameset、img 或具有 name 内容属性的 object 元素，其值为name，或
- 具有值为name的id内容属性的HTML 元素。
来源：HTML 5 规范，“窗口对象的命名访问”，重点是我的。
基于此，符合标准并不是避免这种模式的理由。但是，规范本身建议不要使用它：
作为一般规则，依赖于此将导致代码脆弱。例如，随着新功能添加到 Web 平台，最终映射到此 API 的 ID 可能会随时间变化。而不是这个，使用
document.getElementById()或document.querySelector()。
很好的问题。正如爱因斯坦可能没有说的那样，事情应该尽可能简单，而不是更简单。
如果有人无意中尝试在更广泛的范围内重新定义 myDiv（虽然这不是一个绝妙的主意......），后一种方法的优点是保持代码安全，并用一些不同的值覆盖它并在没有注意到冲突的情况下继续进行
这就是为什么这是一个坏主意的主要原因，而且已经足够了。依赖全局变量是不安全的。它们可以随时被最终在页面上运行的任何脚本覆盖。
除此之外，仅仅输入myDiv不是document.getElementById(). 它是对全局变量的引用。如果元素不存在，它document.getElementById()会很高兴地返回null，而尝试访问一个不存在的全局变量将抛出一个引用错误，因此您需要将您对全局变量的引用包装在 try/catch 块中以确保安全。
这就是 jQuery 如此受欢迎的原因之一：如果你这样做了$("#myDiv").remove()，并且没有 id 为 的元素，myDiv则不会抛出错误——代码只会默默地什么都不做，这通常正是你在进行 DOM 操作时想要的。
有几个原因：
你不希望你的代码和你的标记耦合。
通过使用特定调用来访问 div，您不必担心全局空间被破坏。添加一个myDiv在全局空间中声明的库，您将进入一个难以修复的痛苦世界。
您可以通过 ID 访问不属于 DOM 的元素
它们可以位于片段、框架或已分离但尚未重新附加到 DOM 的元素中。
编辑：通过以下方式访问非附加元素的示例 ID
var frag = document.createDocumentFragment();
var span = document.createElement("span");
span.id = "span-test";
frag.appendChild(span);
var span2 = frag.getElementById("span-test");
alert(span === span2);就我而言，我的页面中有一个 iframe。我id对属性 vsname属性感到困惑，这两者都影响了一个名为 的变量inner_iframe，可从window!
如果我只使用id 属性，比如id="inner_iframe"， window.inner_iframe就是一个HTMLIFrameElement. 属性包括inner_iframe.contentDocument 并inner_iframe.contentWindow 如此处所述*
window因为@joew 在接受的答案中引用的原因：
具有值为 name的id内容属性的HTML 元素
如果我只使用name 属性，name="inner_iframe"那么就像window.inner_iframe一个“框架”，又名“窗口对象”。contentWindow，故而得名属性inner_iframe并没有具有属性contentDocument或contentWindow。
inner_iframe变量出现是window 因为@joew 在接受的答案中引用的原因
名称为 name的活动文档的子浏览上下文
name和id属性，我给这两个属性的值相同name="inner_iframe" id="inner-iframe"; 的name属性捏造/重挫的id属性; 我被留下的“窗口对象”，不是的HTMLIFrameElement！所以我的观点是要小心歧义；具有两个不同 API 的同一对象上的name和id属性之间的冲突：只是一种特定情况，其中隐式行为和窗口变量的附件可能会使您感到困惑。
*（并且仅当在 HTML 中的<script>之后/之下加载<iframe>，或者在尝试通过 id 属性访问之前<script>等待window.onload）
**这个“框架”与 DOM 元素的区别在 Mozilla 文档中描述为：
window.frames 伪数组中的每一项都表示对应于给定 's or 's 内容的 window 对象，而不是 (i)frame DOM 元素（即 window.frames[0] 与 document.getElementsByTagName 是一回事("iframe")[0].contentWindow)。