id 总是赢过 .class 是因为 CSS 权重比较按四元组 (内联, ID, 类/伪类/属性, 标签/伪元素) 从左到右逐位判定，#header 的 (0,1,0,0) 第二位 1 > 0，直接胜出 .nav 的 (0,0,1,0)，后续位不参与比较。

为什么 #id 总是赢过 .class？看权重四元组怎么比

ID选择器优先级高，不是因为“它更厉害”，而是CSS层叠规则里有一套严格的四元组比较机制：(内联, ID, 类/伪类/属性, 标签/伪元素)。#header 的权重是 (0,1,0,0)，.nav 是 (0,0,1,0) —— 比较时从左往右，第二位 1 > 0，直接胜出，后面两位根本不会被看。

• 哪怕你写十个 .btn.btn.btn...，加起来仍是 (0,0,10,0)，依然不敌一个 #main
• 权重不进位：10 个 class ≠ 1 个 ID；就像十张 10 元钞票买不了标价 100 元但只收百元整钞的自动贩卖机
• 浏览器不计算“总分”，只做“逐级判别”——这是 W3C 规范明确要求的

当 ID 和 class 同时作用于一个元素，谁生效？

实际开发中常遇到：<div id="user" class="card active">，同时有 #user { color: red; } 和 .card { color: blue; }。结果一定是红色——ID 规则胜出，哪怕它在 CSS 文件里写在前面。

• 顺序只在权重相等时起作用（比如两个 .card 冲突）
• 如果想让 class 覆盖 ID，唯一合规做法是提高 class 的具体性，例如 #user.card { color: blue; }（权重变为 (0,1,1,0)）
• 用 !important 强行覆盖虽可行，但会破坏可维护性；尤其在组件化项目中，容易引发下游样式意外失效

ID 选择器的高优先级，在现代工程中是优势还是包袱？

理论上 ID 权重高利于精准控制，但实践中它常成为重构和复用的障碍：

vue-composition-api-best-practices

Vue 3 组合式 API 与 最佳实践，涵盖代码组织、useXxx 模式、组合式函数设计、Store 集成、响应式优化及功能抽取。

下载

• ID 必须全局唯一，组件隔离困难；React/Vue 中动态生成 ID 易出错，SSR 下还可能水合 mismatch
• CSS-in-JS 或原子化方案（如 Tailwind）默认回避 ID 选择器，正是为规避权重失控风险
• 调试时发现某个样式死活不生效？先查有没有隐藏的 #sidebar .item 在后台悄悄压制你的 .menu-item

想绕过 ID 权重又保持语义，有什么替代方案？

不用 ID 并不意味着放弃语义或精确控制。真正可控的方式是提升选择器“具体性”而非依赖 ID：

• 用属性选择器代替 ID：比如 [data-section="header"] 权重同 class（(0,0,1,0)），且无全局唯一限制
• 组合 class 实现唯一性：.header.is-fixed.is-scrolled 既可表达状态，又便于 BEM 命名和复用
• 借助嵌套上下文提升权重：.layout-main .user-card（(0,0,2,0)）比单个 #user-card 更易测试、拆分和覆盖

真正难的不是算清 (0,1,0,0) 和 (0,0,1,0) 谁大，而是在团队协作中让所有人默认避开 ID 作为样式钩子——因为一旦用了，它就永远站在权重链顶端，等着某天被误删后引发一连串“为什么样式突然变了”的排查。