id属性必须全局唯一，否则getElementById只返回首个匹配元素，导致JS逻辑错误、样式失效及ARIA关联失败；应使用小写字母、数字和连字符命名，仅用于锚点跳转、表单关联、ARIA引用和单元素精准控制。
id属性必须全局唯一，否则 getElementById 会返回第一个匹配元素
浏览器不阻止重复 id，但所有依赖它的机制都默认“只存在一个”。document.getElementById('save-btn') 永远只返回 DOM 中第一个 id="save-btn" 的元素，哪怕你页面里渲染了 10 个相同 id 的按钮。JS 逻辑大概率因此中断，比如点击第 5 个按钮却触发了第 1 个的事件处理函数。
常见诱因包括：
- 模板循环中写死
id="delete-item"，没拼接唯一标识（如id="delete-item-{{id}}"） - Vue/React 组件多次挂载，静态 id 被复用
- iframe 内容也参与全局 id 唯一性校验，主页面和 iframe 里不能有同名 id
id 值不能含点、冒号、空格，否则 CSS 和 querySelector 会失效
id="user.email" 或 id="btn:submit" 在 HTML 解析上合法，但实际工程中等于埋雷：
- CSS 中
#user.email被解析为「id=user 且 class=email」，不是你想选的元素 -
document.querySelector('#user.email')同样失败；只有document.getElementById('user.email')能取到，但样式和事件委托完全脱节 - 转义写法如
#user\.email易错、难维护，应直接避免
安全命名只用小写字母、数字、连字符：id="user-profile"、id="search-input"。别用驼峰（userProfile），也别以数字开头（id="1st-section" 兼容性差）。
该用 id 的场景其实很少，多数时候 class 或 data-* 更合适
id 不是“高级 class”，它的语义是「全页唯一锚点」。以下才是合理使用场景：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 锚点跳转：如目录链接
<a href="#section-3">对应<section id="section-3"> - 表单关联：
<label for="email-field">必须指向一个真实存在的id="email-field" - ARIA 关联：
aria-labelledby="title-desc"依赖目标 id 存在且唯一 - 需要 JS 精准控制单个元素（如模态框容器
id="modal-confirmation"）
反例：id="primary-button"、id="card-item" —— 这些是类型描述，不是唯一标识，应该用 class="btn-primary" 或 data-role="card"。
动态生成 id 时，服务端和客户端必须保持一致
SSR（服务端渲染）+ Hydration（客户端激活）场景下，若服务端生成 id="item-123"，而客户端 JS 又生成 id="item-456"，React 会报 mismatch 警告，Vue 可能丢弃事件绑定。
解决办法：
- 服务端与客户端共用同一套 id 生成逻辑（如基于数据 ID 拼接）
- 避免用时间戳、随机数等不可控值做 id 主干
- 实在无法保证稳定，改用
data-id存业务标识，用querySelector('[data-id="123"]')替代getElementById
最易被忽略的一点：id 一旦同时用于 CSS 样式、JS 获取、ARIA 关联和锚点跳转，就形成强耦合。改一个地方的 id，四类逻辑都要同步检查——这不是技术限制，而是人为引入的维护负担。
