itcss目录应严格按settings→tools→generic→elements→objects→components→trumps七层组织，每层职责隔离：settings仅存变量，tools封装mixin/function，generic做重置，elements定义裸标签，objects抽象布局模式，components实现具名业务模块，trumps专管!important覆盖。
ITCSS分层结构到底该怎么组织文件目录
ITCSS不是靠命名约定糊弄过去的东西，它要求每一层的样式必须严格按职责隔离，否则components层改个margin，objects层的栅格就塌了。真实项目里最常崩的是把trumps（覆盖层）写得太早，或者把components和utilities混着用。
推荐目录结构（从上到下编译顺序即层叠顺序）：
-
settings/：仅:root变量、断点$breakpoints、z-index映射$z-indexes，不写任何选择器 -
tools/：Sass@mixin（如fluid-type()）、@function（如rem-calc()），不输出CSS -
generic/：重置normalize.css、* { box-sizing: border-box; }、默认字体堆栈 -
elements/：裸标签样式，如h1 {}、ul {}、button {}，禁止类名 -
objects/：抽象布局模式，如.o-layout-grid {}、.o-media {}，只用class，不带语义 -
components/：具名功能模块，如.c-card {}、.c-nav {}，可嵌套但深度≤2级，禁止影响外部间距 -
trumps/：仅!important覆盖，如.u-hidden !important、.u-mt-0 !important，必须带u-前缀
为什么components层不能直接引用settings里的变量
能引，但不该引——因为这会制造隐式依赖。当components/card.scss直接读$color-primary，而settings/colors.scss某天被拆成colors-light.scss和colors-dark.scss时，构建不会报错，但主题切换就失效了。
正确做法是让components通过tools/mixins.scss间接消费：
// tools/_mixins.scss
@mixin theme-color($name) {
color: map-get($theme-colors, $name);
}
<p>// components/_card.scss
.c-card {
@include theme-color('primary');
}
</p>
这样变量变更只需改map-get逻辑，所有组件自动适配。
trumps层误用导致样式无法覆盖的典型场景
错误示范：.c-button.u-full-width在HTML里并列使用，结果按钮宽度没变——因为.c-button在components层，.u-full-width在trumps层，但它的权重可能被.c-button里一条width: auto !important锁死了。
排查要点：
- 打开DevTools，看
.u-full-width是否被划掉，如果是，说明有更高优先级的!important在它之后声明 - 检查
trumps是否真在最后编译：Webpack中import 'trumps/all.scss'必须放在main.scss末尾 - 避免在
components里写!important，那是trumps的唯一领地
如何让设计师理解objects和components的边界
别跟他们讲抽象概念。直接给两个截图对比：
左图：一个卡片组件，设计师说“这个卡片要加阴影、圆角、内边距”——这是components，因为它是具体业务单元；
右图：同一张卡片里，头像+文字左右排列的结构——这是objects，叫.o-media，因为它在用户头像、新闻列表、评论项里反复复用，且不绑定任何业务含义。
关键判断标准：如果删掉这个类，UI结构就垮了（比如栅格塌陷），它是objects；如果删掉只是视觉降级（比如少个阴影），它是components或trumps。
真正难的是objects的颗粒度——.o-flex-center太细，.o-article-layout又太重。建议从设计系统里提取出现≥3次的布局模式再建模。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
