css中#id选择器让维护变困难的根本原因是它将样式与dom结构强绑定于“唯一性”，而真实项目中结构、需求和组件复用均要求灵活性，#id却无法适应变化。
为什么 CSS 中的 #id 选择器会让维护变困难？
根本原因就一个：它把样式和 DOM 结构强绑定在“唯一性”上，而真实项目里，结构会变、需求会扩、组件要复用——#id 却没法跟着一起变。
#id 的高特异性（0,1,0,0）是怎么拖慢改样式的？
它的权重是类选择器（.class）的 10 倍。一旦用了 #header 写了样式，后面想微调某个子页面的 header，就得写更重的选择器，比如 .page-about #header，或者加 !important —— 这两种做法都会让后续覆盖越来越难。
- 常见错误现象：
#nav { color: blue; }已存在，结果在移动端需要改成灰色，试了.mobile .nav { color: gray; }却不生效 - 真正原因：不是没写对，而是
.mobile .nav特异性只有 (0,0,2,0)，压不过#nav的 (0,1,0,0) - 实操建议：把
#nav改成.main-nav，再用.mobile .main-nav覆盖，逻辑清晰且可预测
组件化开发中，#id 为什么会直接导致“多实例失效”？
react/vue/Svelte 组件经常需要在同一页面渲染多次（比如多个 #alert-box 写样式，CSS 就只作用于第一个匹配元素；js 用 document.getElementById('alert-box') 也只会拿到第一个 —— 功能和样式双双错乱。
警告1 警告2
警告1 警告2- 使用场景：模态框、表单字段、动态卡片等需批量渲染的 ui 单元
- 参数差异：id 是“定位标识”，class 是“样式契约”——别让它们承担对方的职责
- 性能影响：无实质性能损失，但调试成本指数级上升；chrome DevTools 里搜
#alert-box总显示“1 of 1”，实际 DOM 里却有 5 个
团队协作时，#id 命名冲突有多隐蔽？
不像 .btn-primary 可以加命名空间（.auth-btn-primary），id 没法自然嵌套。两个人同时开发侧边栏模块，一个写了 #sidebar，另一个写了 #side-bar，看着像不同东西，结果都塞进同一个页面，html 合法性被破坏，辅助技术（如读屏器）和 seo 也可能受影响。
立即学习“前端免费学习笔记（深入）”；
- 容易踩的坑：用数字开头（
#1st-section）、含大写字母（#MainNav）或特殊字符（#user@profile）——这些在 HTML 中无效或解析异常 - 实操建议：id 仅用于三类场景：
document.getElementById()调用、锚点跳转、label[for="email"]关联表单控件；其余一律交给 class
维护最难的从来不是写新样式，而是改旧代码时不敢动、不敢删、不敢重命名——#id 在样式层埋下的这个“唯一性地雷”，往往要等到重构组件或接入新框架时才突然引爆。