应使用语义化前缀的 grid 容器类而非通用类，因后者破坏 Grid 容器驱动本质、导致样式冲突与维护困难；推荐单一职责原子类组合，禁用 dense、template-areas 全局基类及 stretch 默认值，并以文档明确轨道策略。
直接用 grid 容器类加语义化命名前缀，不封装“万能网格类”，避免覆盖子项默认行为。
为什么不能写 .grid-12col 或 .grid-auto-fit 这类通用类？
这类类名看似省事，实则破坏 Grid 的容器驱动本质：它们把轨道定义（grid-template-columns）和项目定位逻辑（grid-column）强行解耦，导致后续任何微调都得靠 !important 或内联样式硬顶。更严重的是，当多个团队成员复用同一类名但期望不同行为时（比如有人想让子项自动跨两列，有人想固定占一格），冲突会集中在 HTML 层，CSS 层反而失去控制力。
- Grid 项的布局意图必须由容器声明 + 项目显式归属共同表达，缺一不可
-
repeat(auto-fit, minmax())这类响应式模式依赖父容器宽度和子项最小尺寸，无法脱离上下文抽象成静态类 - 一旦用类名固化了
gap、align-items等属性，就等于锁死了垂直对齐方式，而卡片列表和表单布局对align-items的需求恰恰相反
推荐的基类结构：容器语义前缀 + 可组合原子类
例如后台页面统一用 .layout-dashboard 作为根容器，再叠加功能型原子类：
-
.layout-dashboard：只设display: grid和基础gap，不定义行列 -
.grid-cols-3：仅含grid-template-columns: repeat(3, 1fr) -
.grid-cols-card：含grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)) -
.grid-rows-fixed：含grid-template-rows: 64px 1fr（用于顶部导航+主内容）
所有类都保持单一职责，且命名体现真实用途（如 -card 而非 -auto-fit），方便开发者一眼判断适用场景。
立即学习“前端免费学习笔记（深入）”；
必须禁用的“便利”写法
以下写法在团队协作中极易引发隐性 bug：
- 禁止在基类中写
grid-auto-flow: dense—— 它会打乱 DOM 顺序，影响可访问性和 SEO - 禁止用
grid-area配合grid-template-areas做全局基类（如.grid-layout-main）—— 命名区域必须与具体业务模块强绑定，否则"header | sidebar | main"这种泛化定义在嵌套布局中必然冲突 - 禁止给基类加
justify-items: stretch并设为默认 —— 它会让所有子项强制撑满列宽，导致按钮、开关等行内级元素被意外拉伸变形
真正需要团队共识的，是轨道定义策略而非类名
比类名更重要的是约定好什么场景该用哪种轨道单位：
- 固定功能区（如侧边栏、顶部栏）：用
px或rem - 内容主区域：优先用
1fr，禁用auto（除非明确要包裹内容高度） - 卡片/列表项：必须用
minmax(300px, 1fr)而非minmax(min-content, 1fr)—— 后者在窄屏下可能压缩到文字换行不可读
这些规则写进 CSS 自文档注释里，比塞进类名里管用得多。Grid 的力量不在“多一个 class”，而在容器和项目之间那层清晰的契约关系——一旦这层关系被泛化类名模糊掉，后续所有响应式调整都会变成修修补补的体力活。
