document.getElementById 通常比 document.getElementsByName 更快更稳定，因其基于唯一 id 的哈希查找（O(1)），而后者需遍历 DOM（O(n)）且返回 NodeList；但选择依据应是语义需求而非性能——id 用于 DOM 定位与样式，name 专用于表单提交及 radio 组操作。
直接说结论：document.getElementById 在绝大多数场景下比 document.getElementsByName 快，且更稳定；但“快”不等于“该用哪个”，关键看你要解决什么问题。
为什么 getElementById 通常更快
浏览器引擎对 id 属性做了底层索引优化：每个文档只允许一个元素拥有特定 id，所以查找时可直接哈希定位，时间复杂度接近 O(1)。而 name 没有唯一性约束，document.getElementsByName 必须遍历整个 DOM 树（或至少当前 document 的所有元素），返回一个 NodeList，时间复杂度是 O(n)。
- 即使页面中只有一个
name="username"，它仍要扫描全部元素才能确认“就这一个” -
getElementById不会返回数组，无需后续取[0]，少一层判断和越界风险 - 旧版 IE（如 IE6/7）对
getElementsByName的实现有 bug，可能漏掉动态插入的元素
getElementsByName 的实际使用陷阱
它看起来像“按名字找”，但行为远不如表面直观：
- 返回值永远是
NodeList，哪怕 DOM 中只有一个匹配元素 —— 你必须写document.getElementsByName("foo")[0]才能取到节点，容易忘记下标导致undefined - 某些浏览器（如早期 Safari）对
name属性的支持仅限于表单控件（input、select、textarea、button、form），对div或span加name不生效 - HTML5 已明确将
name视为表单相关属性，非表单元素加name属于无效 markup，校验工具会警告 - 服务端接收不到没写
name的表单控件值，但前端 JS 查找不到它们也不影响提交 —— 这说明“查找”和“提交”是两个正交需求
什么时候必须用 name 而不是 id 查找
极少，但存在真实场景：
- 处理一组
radio按钮时，需通过相同name获取全部选项：document.getElementsByName("gender")，再遍历判断哪个被选中 - 兼容老系统（如某些银行内网页面）仍依赖
document.formName.elementName这种 IE 专有写法，本质是靠name链式访问 - 动态生成表单控件后，用
getElementsByName比反复调用getElementById更省事（前提是已知所有控件共享同一name且无其他干扰）
注意：这些都不是“性能驱动”的选择，而是语义或兼容性倒逼的结果。
现代开发中的务实建议
别在性能上纠结 name 和 id 的查找差异 —— 真正拖慢页面的是重复查找、未缓存引用、或在循环里调用 DOM 方法。
- 需要频繁操作某个元素？先
const el = document.getElementById("myId")，后面直接用el - 要提交数据？确保控件有
name，id只用于样式或脚本定位，二者可以并存：<input id="userEmail" name="email"> - 想用 CSS 选中？只能靠
id（#userEmail）或class，name无法被 CSS 选择器匹配 - 用框架（React/Vue）？基本不需要手动查 DOM，
name和id都退居为声明式配置项，性能差异已无关紧要
最常被忽略的一点：name 的语义绑定在表单提交链路上，而 id 绑定在 DOM 结构和客户端交互上。混淆二者，往往不是慢一点的问题，而是功能直接失效 —— 比如漏写 name 导致后端收不到值，这种错误不会报 JS 异常，却极难排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
