id必须全局唯一且命名规范，重复会导致js获取元素异常、css行为不一致；应避免数字开头、特殊字符及保留字，优先使用语义化连字符命名；仅在锚点跳转或aria关联等必要场景使用id，其他情况推荐class或data-*属性。
id 必须全局唯一，重复会导致 JS 和 CSS 行为异常
HTML 中 id 是文档级唯一标识符，浏览器不校验重复，但一旦出现多个相同 id，document.getElementById() 只返回第一个匹配元素，CSS 选择器 #my-id 仍会命中所有（这是未定义行为，不同浏览器渲染可能不一致）。实际开发中，重复 id 最常引发「JS 找不到元素」或「事件只绑定到第一个」这类隐性问题。
- 服务端模板循环生成 DOM 时，容易把
id="item"写死在循环体里——必须用动态值，比如id="item-<span>{i}</span>" - 组件化场景（如 Vue/React）中，子组件若声明静态
id，父组件多次引用就会冲突——应通过 prop 注入前缀，或改用data-id - SSR + 客户端 Hydration 时，服务端和客户端生成的
id不一致，会导致 React 警告或 Vue mismatch ——需确保两端生成逻辑完全同步，或干脆避免用id做状态锚点
id 命名不能以数字开头，也不能含空格、点、冒号等特殊字符
HTML5 规范允许 id 包含字母、数字、连字符（-）、下划线（_）、冒号（:）和点（.），但 CSS 选择器和 JS 的 getElementById() 实际支持有限：以数字开头的 id 在 CSS 中必须写成 #\31 23 这种转义形式；含点或冒号的 id 会让 document.querySelector("#user.name") 直接解析失败（因为点被当成 class 选择器）。
- 安全做法：只用小写字母 + 连字符，例如
id="search-input"，不写id="1st-item"或id="user.email" - 需要语义化分隔时，优先用连字符而非下划线（
nav-toggle比nav_toggle更通用，且兼容旧版 IE） - 避免使用 JavaScript 保留字（如
id="for"、id="class"），虽然 HTML 允许，但某些老框架或工具链会误解析
不要为了样式或 JS 绑定强行用 id，class 和 data-* 更合适
很多人习惯给按钮加 id="submit-btn" 只为写一行 document.getElementById("submit-btn").addEventListener(...)，这既破坏可复用性，又让 CSS 选择器权重过高（#submit-btn 会压过大多数 class 规则）。现代开发中，id 应仅用于真正需要「锚点跳转」或「ARIA 关联」（如 aria-labelledby）的场景。
- 纯功能绑定：用
class="js-submit"或data-action="submit"，再用document.querySelector("[data-action='submit']") - 关联表单控件与标签：用
for属性指向id是合理场景，但id本身应简短、稳定，如id="email-field" - 页面内跳转链接（如目录导航）：
id是唯一可靠方式，此时命名要兼顾可读性和 URL 友好性，避免空格和中文，例如id="usage-example"
自动化检查比人工更可靠，推荐轻量级验证手段
靠肉眼检查几十个组件里的 id 是否重复或命名合规，效率低且易漏。简单脚本就能覆盖大部分风险点。
立即学习“前端免费学习笔记（深入）”；
- 控制台快速查重：
[...document.querySelectorAll('[id]')].map(el => el.id).filter((v, i, a) => a.indexOf(v) !== i)—— 返回所有重复的id值 - 检查非法字符：
[...document.querySelectorAll('[id]')].filter(el => !/^[a-zA-Z][a-zA-Z0-9\-_]*$/.test(el.id))—— 找出不符合命名规范的元素 - 构建时集成：用 ESLint 插件
eslint-plugin-jsx-a11y（对 JSX）或 HTMLHint（对纯 HTML）配置id-naming-convention和id-unique规则
真正麻烦的不是命名规则本身，而是跨团队、跨框架、跨构建流程时，id 的生成逻辑分散在模板、JS、配置文件甚至后端代码里——统一收口到一个 ID 工厂函数（比如 genId("modal", "user") → "modal-user-1"）比记住所有规范更有效。
