SMACSS中基础类（Base）仅定义语义化元素的全局默认样式，如a、h1、p等，使用元素选择器，不带类名或ID，不写!important，不设margin/padding，不包含组件类或属性选择器。
SMACSS里基础类（Base）该放什么
基础类不是重置样式，而是定义全局默认行为。它只作用于元素选择器（h1、p、button），不带类名或ID，也不用!important。
常见错误是把字体大小、行高全塞进body，结果被后代元素继承出错；或者在Base里写.btn这种具体组件——这属于模块层。
- 只写语义化元素的默认样式：比如
a { color: #007bff; text-decoration: none; } - 设置统一的
box-sizing: border-box，但别在这里改margin或padding（那些归布局或模块管） - 避免使用属性选择器如
[type="submit"]——它已超出“基础”范畴，属于模块或状态
布局类（Layout）和容器类（Container）怎么分
Layout 是页面骨架，比如.header、.main、.sidebar，它们控制区域位置与尺寸，通常用display: flex或grid，且内部子元素用class明确归属。
容易混淆的是“居中卡片”这种需求：如果它是通用容器（如.l-center），属于Layout；如果它只用于用户头像展示区（.profile-card），就该归到模块层。
立即学习“前端免费学习笔记（深入）”；
- Layout 类名建议加
l-前缀（如l-header），避免和业务模块名冲突 - 不要在Layout里写颜色、字体、边框——这些是模块或主题的事
- 响应式断点调整也应放在Layout层，而不是每个模块里重复写
@media
模块类（Module）命名和嵌套边界在哪
模块是可复用的UI单元，比如.carousel、.pricing-table。它必须能独立存在、单独测试，且不依赖父容器结构。
典型翻车现场：写.sidebar .btn来改侧边栏按钮样式——这破坏了模块的可移植性；正确做法是给按钮加.btn--sidebar或让模块自身包裹并控制子元素。
- 模块内允许子元素选择器，但层级建议≤3层，例如
.card .card__header h3可接受，.card .card__body .content p strong就该重构 - 状态样式（如
.is-active、.is-loading）必须和模块同级声明，不能藏在模块内部写.module .is-active - 避免用
id写模块样式——#search-input无法复用，应改为.search-form__input
为什么SMACSS不单独设“主题类”或“工具类”
SMACSS原始文档没提Theme或Utils，因为它的五类（Base / Layout / Module / State / Theme）中，Theme本就是可选项，而现代工程中utility classes（如u-mt-2）常由PostCSS插件或Tailwind生成，不属于手写CSS的组织逻辑。
硬塞工具类进SMACSS目录，反而模糊了关注点：一个u-text-center既可能用于Layout的标题对齐，也可能用于Module内的按钮组——它的归属取决于上下文，而非自身性质。
- 若项目用BEM+SMACSS混合，工具类建议单独建
utils.css，不在SMACSS主分类中占位 -
State类（如.is-hidden）必须是布尔型、无样式细节，只负责显隐/启用等开关，别在里面写transform: scale(0.95) - 真正难处理的是跨模块状态联动，比如
.cart.is-expanded .product-list——这时应提升到Layout层协调，而非让模块互相耦合
State层的抽象：大家习惯直接写.menu.open，却忘了.is-open才是可复用的状态钩子。这点一旦忽略，后续换肤、无障碍、服务端渲染状态同步都会变棘手。 
