ID选择器在CSS中应避免使用，因其权重过高（100分）导致覆盖困难、阻碍样式复用与团队协作；JS操作应改用类名或data属性，HTML中可保留ID用于无障碍或跳转，但CSS中禁用ID选择器。
ID选择器在CSS中几乎不该出现——不是不能用，而是它天然违背样式复用、团队协作和渐进式维护的基本前提。
为什么#header比.header更容易让你改不动样式
CSS权重不是“谁写在后面谁赢”，而是硬性计算：#header是100分，.header是10分，.header.is-scrolled是20分。这意味着：哪怕你只改一个子元素的颜色，只要父级用了#nav，你就得写#nav .nav-link:hover（110分）或加!important才能覆盖。
常见错误现象：
-
#user-panel .btn已存在 → 后续想给某个页面的按钮加圆角，写.user-panel__btn--rounded完全不生效 - 用
!important临时压过ID后，下个需求要改文字颜色，又得再加一层更高权重的选择器 - DevTools里看到“已应用”样式，但实际渲染却是旧值——因为另一个
#layout规则在更上层悄悄覆盖了
组件化场景下document.getElementById()为什么越来越不可靠
React/Vue里一个<alert></alert>组件可能被渲染5次，但id="alert-box"只能合法存在一次。浏览器会静默忽略重复ID，document.getElementById('alert-box')永远只返回第一个，而CSS规则却可能随机作用于某个实例。
立即学习“前端免费学习笔记（深入）”；
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
实操建议：
- JS操作统一走
document.querySelector('.alert-box')或document.querySelectorAll('.alert-box')，类名天然支持多实例 - 需要唯一锚点时，用动态生成的
id（如id="alert-123"）配合aria-labelledby，但CSS里只认.alert-box - 测试环境或E2E脚本中，改用
[data-testid="alert-close"]代替ID，避免和生产代码耦合
BEM类名怎么写才不会意外继承ID的权重陷阱
BEM本身不降低权重，关键是你别把“看起来更具体”当成安全网。这些写法看似合理，实则权重翻倍：
-
.card .card__title→ 权重20（两个类），应直接写.card__title -
h3.card__title→ 权重11（标签+类），BEM约定不依赖HTML结构，删掉h3 -
.button--primary.button--loading→ 权重20，合并为.button--primary--loading或拆成独立状态类
真正有效的降权动作，是删掉那行#sidebar-nav。一旦CSS里没有ID，后续所有主题切换、暗色模式适配、微前端样式隔离都会少一层隐性约束——这个转变往往就卡在第一次有人把getElementById改成querySelector的瞬间。
最常被忽略的点：ID在HTML里可以存在，但只要它没出现在CSS选择器中，权重问题就不存在。保留id="main-content"用于跳转或aria-属性完全没问题，但#main-content { padding: 20px; }这行必须删掉。
