Base类不该加b-前缀，因其是全局基础样式，加b-会误导为业务模块私有依赖，削弱可复用性；应统一用base-前缀并前置加载。
Base类该不该加b-前缀？
不该。Base类是全局基础样式，比如重置默认边距、字体栈、按钮默认状态，它不绑定具体组件，也不该被某个block私有化。加b-会误导开发者以为它是某个业务模块的底层依赖，反而削弱其“全局可复用”语义。真实项目里，b-reset或b-button这种命名会让后续维护者不敢动——怕影响其他地方，结果 Base 类越积越多，最终变成没人敢改的黑盒。
建议统一用base-前缀（如base-button、base-text），并在构建时通过@import或CSS-in-JS的injectGlobal提前载入，确保它在所有组件样式之前生效。
Component如何安全继承Base样式而不污染自身BEM结构？
直接class="button base-button"是常见做法，但风险在于：一旦base-button未来加了display: inline-flex，而某个业务按钮需要display: block，就会产生不可控覆盖。更稳妥的方式是用@extend（Sass）或CSS自定义属性桥接：
- 用Sass时，在
button.scss中写@extend %base-button，把Base定义为占位符（%base-button），而非真实class，避免HTML中暴露Base类名 - 用原生CSS时，把Base中可变部分抽成
--base-btn-padding、--base-btn-bg等变量，在Component中仅覆写需要的部分，保留BEM的button__icon这类子元素结构不变 - 禁止在Component样式里用
.base-button {...}做嵌套选择器，那会破坏BEM“一个class对应一个样式职责”的前提
当Base和Component同名样式冲突时，优先级怎么控制？
CSS权重不是靠前缀长度决胜的，而是看选择器具体性。一个.base-button（1 class）永远赢不了.header__nav-item.button--primary（2 classes）。所以别指望base-前缀能天然“压过”组件样式。
真正可控的做法只有两个：
- 构建时保证Base CSS文件在Bundle中排最前（Webpack中
style-loader+mini-css-extract-plugin需确认base.cssimport顺序靠前） - 对必须强覆盖的Base规则（如
box-sizing: border-box），用!important——这不是妥协，而是明确声明“此为基础设施级契约”，就像Normalize.css里做的那样 - 避免在Base里写带伪类或属性选择器的规则（如
.base-button:hover），这类规则容易被Component中更具体的选择器绕过，且难以调试
要不要为Base单独建base/目录并拆出base.layoutbase.typography等文件？
要，但别按视觉类型分，而要按“是否会被Component直接消费”来切。比如base.reset（强制统一默认值）、base.utils（.u-hidden、.u-flex-center等工具类）必须独立；但base.typography如果只含font-family和line-height变量，就该合并进base.tokens，而不是让每个Component都去@import一堆“看起来有用但实际没调用”的样式文件。
关键判断标准：这个Base文件是否在至少3个不同Block中被@include或@extend？如果不是，它大概率还没到成为Base的成熟度，先收进Component内部更安全。很多团队过早抽象Base，结果Base成了新包袱——改一个base.spacing，全站按钮、卡片、表单间距全乱，就是没卡住这个门槛。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
