用 #id 选择器能精准匹配唯一元素，但“唯一”不等于“一定生效”
HTML 中 id 属性本应全局唯一，#my-header 这类选择器天然权重高（100），比类名（10）、标签（1）都强。但它不是“免死金牌”——样式是否最终生效，取决于层叠顺序和声明位置，而非仅靠 ID 的存在。
- 多个
#id规则共存时，后声明的会覆盖先声明的（同权重下，CSS 遵循“就近原则”） - 如果某处用了
!important，哪怕 ID 选择器也压不住它 -
id值含特殊字符（如点号、冒号）必须转义：#user\.name→ 否则会被解析成类名或伪类
为什么加了 #header 样式却没变？检查这三处
常见现象是写对了 ID、DOM 也存在，但样式不渲染。问题往往不在选择器本身，而在上下文干扰：
- 元素实际没有
id="header"，而是class="header"—— 混淆 class 和 id 是高频错误 - CSS 文件加载顺序错乱：后引入的 reset.css 或框架样式（如 Bootstrap）重置了你的
#header规则 - 父容器设置了
display: none或visibility: hidden，子元素再高的权重也看不见
#id 选择器在 JS 中被误用导致样式失效
用 document.getElementById('nav') 获取元素后，若紧接着用 element.style.color = 'red'，就等于给该元素加了内联样式——它的优先级（1000）高于任何外部 #nav 规则，会导致你写的 CSS 被绕过。
- 避免直接操作
style属性，改用element.classList.add('active')配合 CSS 类控制样式 - 真要动态改样式，可用
element.setAttribute('style', 'color: red; font-size: 14px;')，但注意这会覆盖全部内联样式 - 调试时看浏览器开发者工具的“Computed”面板，确认哪条规则被 strike-through（划掉），就能立刻定位冲突源
ID 选择器不是性能银弹，现代项目中慎用
虽然 #app 看起来高效，但实际影响有限，且带来维护风险：
立即学习“前端免费学习笔记（深入）”；
- 浏览器引擎对 ID 选择器的查找优化早已成熟，和类名差别微乎其微；别信“ID 快一百倍”这种过时说法
- ID 不支持复用，组件化场景下（比如 Vue/React 多个相同卡片），硬套 ID 会违反唯一性，导致 JS 逻辑出错或样式错乱
- CSS-in-JS 或 CSS Modules 方案里，ID 几乎无用武之地——它们默认作用域隔离，靠生成唯一类名解决定位问题
真正容易被忽略的是：ID 一旦用于 JS 绑定事件或获取节点，就和样式强耦合。改个样式可能得同步改 JS，这种隐式依赖比权重高低更难排查。
