id必须唯一，用于锚点跳转、label关联、js高频单元素操作及aria引用；class天然复用，适用于样式、状态、批量操作和组件化开发，日常应优先使用class，仅在需唯一标识时用id。
ID 和 Class 不是“选哪个好”的关系，而是“该用哪个就用哪个”——ID 必须唯一，Class 天然复用；混着用或强行替代，迟早出问题。
什么时候必须用 id？
只有当你要精准锚定单个元素，并且这个定位有明确语义或功能依赖时，才用 id：
- 页面内锚点跳转，比如
@#@#@#@#@#@#@#@#@#@0对应<div id="section3"></div> - 表单中
<label for="email"></label>关联<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"></button>，分别控制基础样式、主题变体、运行态 - 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 就不会选错。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
