不应从零编写Grid/Flex布局系统，因其易导致语义混乱、响应式断裂等问题；应基于原生CSS能力，用自定义属性+类名约定构建语义化、可配置的布局骨架，统一使用display: grid并借助:where()、@container等提升可维护性。
为什么不要从零写 Grid 或 Flex 布局系统
直接封装 display: grid 或 display: flex 的“布局系统”，往往在项目中期就会暴露维护问题：语义混乱、响应式断裂、嵌套冲突、调试困难。浏览器原生布局能力已经足够强大，真正需要自定义的不是“怎么排元素”，而是“怎么组织布局意图”——比如 .layout-header-main-footer、.layout-sidebar-main 这类可复用、可组合、带默认行为的结构单元。
用 CSS 自定义属性 + 类名约定构建布局骨架
不写 JS 控制流，也不生成内联样式，靠纯 CSS 实现可配置的布局结构。核心是把“变化点”抽成 --gap、--sidebar-width、--header-height 等自定义属性，再用类名触发不同布局模式。
- 所有布局容器统一用
display: grid，避免在 flex/grid 之间切换导致逻辑分裂 - 主结构类名如
.layout-hf（header–footer）、.layout-sb（sidebar）只负责定义grid-template-areas和基础轨道尺寸 - 通过
:where()降低选择器权重，防止被业务样式覆盖
:where(.layout-hf) {
display: grid;
grid-template-areas:
"header"
"main"
"footer";
grid-template-rows: var(--header-height, 64px) 1fr var(--footer-height, 48px);
gap: var(--gap, 0);
}
:where(.layout-hf > [data-area="header"]) { grid-area: header; }
:where(.layout-hf > [data-area="main"]) { grid-area: main; }
:where(.layout-hf > [data-area="footer"]) { grid-area: footer; }
响应式不是加 media query，而是按视口分层定义变量
把断点逻辑收进 CSS 自定义属性里，而不是每个布局类都写一遍 @media。这样改一个变量就能全局生效，也方便后续接入 JS 动态控制（比如暗色模式下调整 sidebar 宽度）。
- 用
@container替代部分@media，让布局响应更贴近内容容器而非整个视口 - 定义层级变量如
--layout-sm、--layout-md，在根元素或布局组件上设置 - 避免在布局类中硬编码像素值，全部走
var(--xxx)
@container (min-width: 768px) {
.layout-sb {
--sidebar-width: 240px;
}
}
@container (min-width: 1024px) {
.layout-sb {
--sidebar-width: 280px;
}
}
容易被忽略的兼容性与调试陷阱
自定义布局系统最难的不是写出来，而是让团队愿意用、不出错。两个关键点常被跳过：
立即学习“前端免费学习笔记（深入）”；
-
grid-template-areas要求所有子元素必须有grid-area值，否则整行失效；建议用[data-area]属性强制约束，配合 ESLint 规则校验 HTML 结构 - CSS 自定义属性不支持回退到另一个变量（如
var(--a, var(--b))不合法），需要用var(--a, initial-value)写死兜底，或用 JS 注入 fallback - IE 不支持
grid和自定义属性，如果还要兼容，得用@supports降级到 float 或 inline-block，但代价是代码分支爆炸——多数情况应直接放弃 IE
真正的自定义布局系统，不是替代 CSS 原生能力，而是给它加上语义层和约束层。写得越少，越容易长期维护。
