ITCSS规范详解：分层管理样式权重

ITCSS是一种以层级顺序为核心、严格管控CSS加载与权重优先级的架构方法，其六层（settings/tools → generic → elements → objects/components → trumps）绝非随意划分，而是环环相扣的“样式因果链”：错位一层，就可能引发不可预测的覆盖冲突、视觉回退或维护雪崩；它不教你怎么起名，而逼你思考每个样式的生命位置——变量该在最前注入，重置规则必须早于所有组件，布局结构与视觉表现须泾渭分明，工具类只能以无语义、单职责、垫底方式存在；真正考验工程师的，不是背下七层名称，而是在每次写下一个大括号时，本能地自问：它属于哪一层？有没有悄悄越界？有没有给下一层埋下补丁陷阱？

ITCSS 不是命名规范，而是 CSS 架构分层方法；用错层级顺序，样式权重冲突和覆盖逻辑就彻底失控。

为什么 layers 顺序不能调换

ITCSS 的六层（settings、tools、generic、elements、objects、components、trumps）本质是 CSS 加载顺序 → 决定选择器权重生效优先级。把 components 放在 generic 前面，button { margin: 0 } 就可能被后面加载的 * { box-sizing: border-box } 意外重置。

• settings 和 tools 必须最前：存放 $color-primary、@function rem() 等，不输出 CSS
• generic 紧随其后：*, ::before, ::after、html、body 等全局重置，影响所有后续规则
• trumps（如 !important 工具类）必须垫底：否则会被中间层无意覆盖，.u-hidden 失效

@import 顺序写错等于白搭 ITCSS

SCSS 中靠 @import 控制加载顺序，但很多人把 components/_card.scss 直接 import 到主文件顶部，破坏了层级流。ITCSS 要求所有导入严格按层归类、集中管理。

• 主入口 main.scss 只做七次 @import，每层一个，顺序不可乱
• 禁止在 components/ 文件夹里 @import '../tools/functions'：工具应已在 tools 层提前注入，重复引入会污染作用域
• Webpack/Vite 下若用 @use 替代 @import，需确保模块路径与 ITCSS 层级物理结构一致，否则 @use 'tools/functions' 可能被解析为相对路径而非逻辑层

objects 和 components 容易混用

对象（object）是抽象布局模式，比如 .o-layout-grid、.o-media；组件（component）是具体业务单元，比如 .c-card、.c-header。混用会导致复用性崩塌和样式泄漏。

• objects 不含颜色、字体、间距等视觉属性，只管结构和容器行为
• components 可以基于 objects 组合，但自身必须封闭：不能依赖 .c-card .o-media 这种跨层耦合选择器
• 常见错误：.c-button 里写 &:hover { @include o-layout-grid; } —— 把布局逻辑塞进组件，违反关注点分离

为什么 trumps 层禁用语义类名

trumps 是最后执行的覆盖层，只放无上下文的“暴力工具”，比如 .u-text-center、.u-mt-0。一旦起名带业务含义（如 .u-product-card-hidden），就违背了它的设计意图：即插即用、随处可覆、不绑定 DOM 结构。

• 命名必须以 u- 开头，且仅描述单一视觉行为
• 禁止在 trumps 里写媒体查询组合：如 .u-mt-2@sm 应拆成独立文件 _trumps-responsive.scss，否则破坏加载时序稳定性
• 如果项目用了 Tailwind，trumps 层就基本不用手写 —— 但得确认 Tailwind 的 @layer utilities 是否真被注入在 ITCSS 的 trumps 位置，否则 class="u-hidden md:u-block" 可能被前面层的 [hidden] 规则压制

真正难的不是记住七层名字，而是每次加一个新样式时，下意识问自己：它属于哪一层？有没有偷偷跨层引用？有没有让下一层不得不打补丁来修复上一层的副作用？

今天关于《ITCSS规范详解：分层管理样式权重》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！