index.html里的ID和Class选哪个好

ID必须唯一，用于锚点跳转、label关联、JS高频单元素操作及ARIA引用；class天然复用，适用于样式、状态、批量操作和组件化开发，日常应优先使用class，仅在需唯一标识时用id。

ID 和 Class 不是“选哪个好”的关系，而是“该用哪个就用哪个”——ID 必须唯一，Class 天然复用；混着用或强行替代，迟早出问题。

什么时候必须用 id？

只有当你要精准锚定单个元素，并且这个定位有明确语义或功能依赖时，才用 id：

• 页面内锚点跳转，比如 <a href="#section3">跳到第三部分</a> 对应 <div id="section3"></div>
• 表单中 <label for="email"> 关联 <input id="email">，否则可访问性（a11y）和点击聚焦会失效
• JavaScript 需要高频、独占式操作的元素，比如 document.getElementById('modal-overlay')，尤其在模态框、主菜单等全局组件中
• 被 aria-labelledby、aria-describedby 等 ARIA 属性引用的目标元素

为什么日常样式几乎不用 id？

CSS 中 #header 的特异性（0,1,0,0）远高于 .header（0,0,1,0），看似“更有力”，实则埋雷：

• 一个 #nav 样式写死之后，后续想用 .nav--mobile 覆盖它，得写成 #nav.nav--mobile 或更高特异性的组合，越改越重
• 组件化开发中，第三方 UI 库或微前端子应用若也用 id 写样式，极易互相覆盖或冲突
• id 无法复用，哪怕两个按钮逻辑一致、样式相同，也得复制一遍样式规则，违背 CSS DRY 原则
• 浏览器不校验 id 是否重复，但 document.getElementById() 总是返回第一个匹配项——JS 行为变得不可靠

class 不只是“写样式用的”，它还能干这些事

别把 class 当成纯样式容器，它的设计初衷就是描述“是什么”和“处于什么状态”：

立即学习“前端免费学习笔记（深入）”；

• 多个类共存：<button class="btn btn--primary is-loading">，分别控制基础样式、主题变体、运行态
• JS 批量操作：document.querySelectorAll('.js-toggle') 比循环查一堆不同 id 更轻量、更可维护
• BEM 命名天然适配：article__title、article__title--large，语义清晰，不怕命名冲突
• 服务端渲染或 SSR 场景下，class 是唯一稳定、可预测的选择器目标——id 在动态生成时极易重复或丢失

最容易被忽略的坑：用 class 模拟 id 功能

有人觉得“反正 JS 也能用 querySelector('.unique-id') 找到唯一元素，那我就全用 class 吧”。这很危险：

• 失去锚点跳转能力：location.hash = 'section2' 不会滚动，因为没对应 id="section2"
• label 关联失效：屏幕阅读器读不到 for 指向的输入框，WCAG 合规性直接不达标
• SEO 可能弱化：搜索引擎仍会利用 id 结构理解页面大纲（尤其 heading + id 组合）
• 调试困难：当你在 DevTools 里看到 20 个 class="main-nav" 却不确定哪个是真正主导航时，已经晚了

真正难的不是语法，是每次写标签前问自己一句：这个标识，是“全世界只有一个”，还是“这类东西可能有几十个”？答完，id 和 class 就不会选错。