HTML规范要求id全局唯一，模板复用易导致重复ID，使屏幕阅读器关联错误表单控件，引发可访问性失效；应避免随机生成ID，优先用语义化前缀（如product-123-price）或data-*属性，并用querySelectorAll替代getElementById处理重复ID场景。
重复ID会让屏幕阅读器找不到对应表单控件
HTML规范要求id必须全局唯一，而模版复用（比如Vue/React组件、服务端include、JS动态渲染）最容易在循环或条件分支里产出多个相同id。一旦label[for]指向的id在页面中出现两次，屏幕阅读器就只能关联到第一个input——用户听到“邮箱地址”却聚焦在错误的输入框上，这是典型的可访问性失效。
常见现象包括：表单验证提示与焦点不匹配、语音导航跳过部分字段、Lighthouse报错“Duplicate ID”且定位到label和input不配对。
- 不要依赖模版引擎自动拼接
id，比如v-bind:id="'email-input'"在v-for里会生成一堆id="email-input" - 避免用
Math.random()生成ID——它不保证唯一，且无法反向映射到语义上下文 - 优先用
data-*属性存业务标识，把id留给真正需要锚点或ARIA绑定的场景
用data-id + querySelectorAll替代getElementById批量操作
当模版已上线、无法立刻改结构时，别硬用document.getElementById()——它只认第一个，后续元素等于“不存在”。改用属性选择器能绕过ID唯一性校验，同时保持逻辑清晰。
比如原模版中多个<input id="price">，可这样安全读取所有值：
立即学习“前端免费学习笔记（深入）”；
const priceInputs = document.querySelectorAll('[id="price"]');<br>priceInputs.forEach(input => {<br> console.log(input.value);<br>});-
querySelectorAll('[id="price"]')返回NodeList，不是单个元素，需遍历 - 性能影响极小，几十个元素完全无感；比
getElementsByClassName多一层语义约束 - 配合
data-row-id="123"能精准定位上下文，比如document.querySelector('[data-row-id="456"] [id="price"]')
动态生成时用有意义的ID前缀而非随机字符串
模版复用的本质是“同一结构在不同上下文中实例化”，所以ID应该反映上下文，而不是靠随机数堆砌。比如商品列表页中每个卡片都有价格输入框，id="price-1"不如id="product-123-price"——后者既唯一，又自带业务语义，方便调试和后续扩展。
- 前缀来源可以是父容器
id（如id="shop-mage"→ 子项id="shop-mage-item-7-price"） - 后端模板可用
{{ product.id }}拼接，前端JS可用el.dataset.productId提取 - 避免用
Date.now()或Math.random()——它们不可预测、不可追溯，不利于日志排查和A/B测试
检查重复ID不能只靠肉眼，要进控制台跑一行命令
模版复用导致的重复ID往往藏得深，手动翻DOM树容易漏。打开开发者工具Console，粘贴这行就能立刻揪出所有违规ID：
[...new Set([...document.querySelectorAll('[id]')].map(el => el.id))].filter(id => [...document.querySelectorAll(`[id="${id}"]`)].length > 1)返回空数组说明安全；返回["submit-btn", "email-field"]就代表这两个ID重复了，得立刻修。
这个命令比document.querySelectorAll('[id]')更准——它先去重再查重，不会把合法的单次ID误判为重复。Lighthouse的Accessibility审计也会报这类问题，但控制台命令能实时验证修复效果。
最麻烦的不是发现重复ID，而是它常和aria-labelledby、aria-describedby等ARIA属性耦合——改一个ID，可能要同步更新三四个关联属性。动手前先确认哪些地方真依赖这个ID，别盲目替换。
