document.getelementbyid 快因浏览器对id做哈希索引，o(1)查找，但id重复时仅返回首个元素，导致事件、样式、锚点、无障碍等功能静默失效且行为不一致。
document.getElementById 为什么快，但一撞 id 就失效
它快是因为浏览器对 id 做了哈希索引，document.getElementById('foo') 是 O(1) 查找；但前提是整个文档里真只有一个 id="foo"。一旦重复，它只返回第一个匹配元素，其余彻底“隐身”——不报错、不中断渲染，只静默失败。
常见错误现象：
- 循环渲染表单时写
<button id="submit"></button>5 次 → JS 绑定事件只生效在第一个按钮上 - CSS 写
#submit { opacity: 0.5 }，不同浏览器可能只作用于第一个，也可能全部生效（行为不一致） - URL 片段跳转
page.html#submit永远只滚动到第一个id="submit" - 屏幕阅读器把多个同名
id当作同一个控件，跳过其余，直接破坏可访问性
控制台会警告：Found 2 elements with non-unique id #submit，但这个警告极容易被忽略。
DOM 树深度超 6 层时，querySelectorAll 也开始变慢
不是节点总数多才慢，是“向上回溯的路径长度”变长。浏览器匹配 CSS 选择器是**从右往左**查的，比如 .card .title，先找所有 .title，再逐个往上检查父级是否含 .card。DOM 越深，每次验证祖先链就越长。
实测数据：DOM 深度从 4 升到 8，getComputedStyle() 平均耗时翻倍；深度达 12 时，低端安卓机单次计算卡顿超 80ms。
快速定位深节点的方法（粘贴到控制台运行）：
(function walk(node, level = 0) {
if (level >= 6) console.log(`深度 ${level}:`, node);
for (let child of node.children) walk(child, level + 1);
})(document.body);
容易踩的坑：
- 用
:last-of-type定位时，若目标被裹在 5 层 div 里，而兄弟元素只在第 2 层，它根本不会被选中——不是伪类失效，是结构切断了同级关系 - 在
<td> 里再嵌套 <code><div>，表格布局本就重，叠加深度会放大重排代价<li> <code>for循环里反复读element.offsetWidth，会强制触发同步布局，每深一层，开销线性增长 - 统一用
class="js-add-to-cart"，靠data-product-id="123"存业务数据，事件委托一次搞定 - 服务端模板中避免循环输出
<input id="nonce">，改用class="js-nonce"+data-form-scope="account"定位 -
data-属性不参与样式或锚点，纯属 JS 数据载体；它没有唯一性要求，也不触发浏览器索引，正因如此更安全、更 scalable - 有意义前缀 + 业务标识：
id="account-form-submit"，而非id="btn-1624589321234" - 现代环境优先用
crypto.randomUUID()，不依赖Math.random()或时间戳拼接 - 生成后立刻用
document.querySelectorAll('[id="xxx"]')校验是否真唯一（别只信自己没写错）
class 和 data-* 才是现代 DOM 定位的主力
当结构可复用、可嵌套（比如 100 个商品卡片），id 就不该是默认选项。它有唯一性硬约束，又参与锚点、无障碍、样式等多重语义，滥用等于自建陷阱。
正确做法：
注意：data- 不是“替代 class 的新 class”，它不承担样式职责。该用 class 控制样式，该用 data-* 携带上下文数据，职责必须分开。
动态生成 id 的唯一可靠场景和底线
只有当组件无法预知上下文、又必须暴露可访问锚点或绑定 <label for="xxx"></label> 时，才需生成唯一 id。但生成逻辑必须可控、可预测。
推荐模式：
绝对不要：el.id += '-' + index —— 容易漏掉关联的 label[for]、aria-labelledby 或 CSS 锚点规则，修复成本远高于预防。
真正难的不是生成唯一字符串，而是确保它在整个文档生命周期内始终唯一、且所有依赖它的部分（JS、CSS、a11y）都同步更新。这点常被忽略，直到上线后某次路由切换或组件复用时突然失效。
