该用.g-header而不是.header，因为.g-是布局类命名空间，专用于结构容器且不带视觉样式，可避免多人协作中样式冲突，确保全局重置和响应式控制的一致性。
什么时候该用 .g-header 而不是 .header
当你在多人协作的中大型项目里维护一套可复用、不打架的样式体系时，命名空间就不是“锦上添花”，而是避免 .modal 被业务页和弹窗组件互相覆盖的刚需。
典型场景包括：多团队共用同一套 CSS 构建工具链；需要将 UI 组件打包为独立 npm 包；或长期迭代中频繁增删模块（比如运营页加个新 banner，不影响已有导航栏样式）。
-
.g-布局类（如.g-header、.g-footer）只管结构容器，不带具体视觉样式，方便全局重置或响应式断点统一控制 -
.m-组件类（如.m-dropdown）封装完整交互逻辑 + 样式，对外暴露有限变量（如--m-dropdown-max-height），禁止直接修改内部结构选择器 -
.j-钩子类（如.j-toggle）只供 JSdocument.querySelector使用，CSS 里绝不写样式，防止 JS 和样式耦合泄漏
.s-current 和 .is-active 的本质区别
两者都表示状态，但 .s- 是约定型前缀，强调“这个类名只表达视觉状态，且由 CSS 控制其存在与否”；而 .is-active 更像 BEM 中的修饰符，语义模糊——它可能由 JS 切换，也可能被误用于结构判断。
关键差异在于维护成本：.s-current 意味着你默认所有状态类都走 CSS classList 切换，且不会在 JS 里写 el.classList.contains('s-current') 做逻辑分支（那是 .j- 的事）。
- 错误用法：
if (el.classList.contains('s-current')) { doSomething() }—— 违反关注点分离 - 正确配合：
.s-current对应transition: background-color .2s，JS 只负责el.classList.toggle('s-current') - 兼容性注意：IE11 不支持
classList.toggle('cls', bool)的第二个参数，需降级为add/remove
为什么 .u-ellipsis 不能写成 .ellipsis
单靠 .ellipsis 容易被业务样式意外覆盖——比如某页写了个 .ellipsis { text-overflow: clip; }，结果所有用了 .u-ellipsis 的地方都失效了。命名空间本质是 CSS 权重之外的一层语义隔离。
更隐蔽的问题是调试成本：.u-clearfix 这种工具类一旦被覆盖，页面布局崩塌却很难定位到是哪个 .clearfix 冲突了；而 .u- 前缀让开发者一眼识别“这是基础设施，别动”。
- 必须保证
.u-类只含单一声明，例如.u-ellipsis { text-overflow: ellipsis; white-space: nowrap; overflow: hidden; }，禁止叠加其他样式 - 禁止在
.u-类里使用后代选择器（如.u-ellipsis p），否则就不再是“工具”，变成“局部样式” - Webpack 或 Vite 构建时建议把
u-*类提取到单独 CSS 文件，避免被业务样式@import错误顺序污染
命名空间不是万能的，这些地方别硬套
小项目、原型页、临时活动页——加命名空间反而拖慢开发节奏。真正要警惕的是“伪命名空间”：比如用 .myproject-header 当作 .g-header，但没配套的规范文档和构建约束，最后变成又长又没用的字符串。
最常被忽略的其实是命名空间的“退出机制”：当一个 .m-slider 组件稳定后，是否允许下游项目用 .m-slider--vertical 扩展？还是必须 fork 后改名？这点不提前约定，半年后就会出现 .m-slider-v2 和 .m-slider-new 并存。
实际落地时，比前缀本身更重要的是：团队是否统一用 PostCSS 插件自动校验命名（如禁止 .header 出现在代码里），以及 CI 是否拦截未声明命名空间的 PR。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
