嵌套grid必须显式声明display: grid，子元素不会继承父级网格能力；grid-area和grid-template-areas作用域仅限直接父容器；fr单位基于当前容器尺寸计算；ie11不支持嵌套grid且无降级方案。
Grid容器里再套Grid，必须显式声明 display: grid
很多人以为父容器设了 grid，子元素自动继承网格能力——不是的。子元素默认仍是普通块级元素，哪怕它在父Grid里是某个 grid-item。想让它自己也变成网格容器，得单独给它加 display: grid 或 display: inline-grid。
常见错误现象：grid-template-columns 在子元素上写了但完全不生效；开发者反复检查父级定义，却漏掉子元素本身没开启Grid模式。
- 子元素要成为网格容器，和它在父布局中是第几个
grid-item无关 - 如果子元素是
flex或block，它的内部样式（比如grid-column）会被忽略 - 嵌套后注意
grid-area的作用域：它只在直接父Grid中有效，不会穿透到祖父级
嵌套Grid的 grid-template-areas 不能跨层级复用
grid-template-areas 是局部声明，每个Grid容器都维护自己的命名区域空间。父级定义的 "header main sidebar" 和子级定义的同名区域完全独立，互不影响。
使用场景：你在一个卡片组件（子Grid）里想复用和外层一样的区域名，比如都叫 content ——可以，但必须在子容器里重新写一遍 grid-template-areas，不能靠继承或引用。
立即学习“前端免费学习笔记（深入）”；
- 父级的
grid-area: content对子Grid内部的子元素无效 - 子Grid中若使用
grid-area，匹配的是它自己定义的grid-template-areas字符串 - 命名冲突不报错，但会导致区域无法定位——这是调试时最常卡住的地方
嵌套Grid的 fr 单位计算基于当前容器尺寸，不是父Grid的轨道大小
fr 是“剩余可用空间”的份额单位，它永远相对于**直接父容器的内联尺寸**（即 padding-box 宽度/高度），而不是祖父容器、也不是父Grid某条轨道的尺寸。这点和 % 不同，% 才可能参考父级宽高，而 fr 只认当前容器内容区大小。
性能影响：嵌套越深，每层都要重新计算一次可用空间，尤其当有 minmax() 或 fit-content() 参与时，浏览器布局开销会上升。
- 子Grid的
grid-template-columns: 1fr 2fr，分的是子容器自身的宽度，不是它所在父Grid轨道的宽度 - 如果父Grid轨道设了
minmax(300px, 1fr)，子Grid仍按自己实际渲染宽度来分fr - 想让子Grid列宽严格对齐父级轨道？别依赖
fr，改用px、rem或clamp()配合width控制
IE11不支持嵌套Grid，且无降级方案
IE11 支持基础Grid（需 -ms- 前缀），但遇到子元素也设 display: -ms-grid 时，会直接忽略该声明，子元素退化为普通块级布局，且不触发任何警告或错误。
兼容性影响：这不是样式失效的问题，而是整个嵌套结构逻辑断裂。如果你的业务还要求支持IE11，嵌套Grid必须整体规避，不能靠条件注释或特性检测局部启用。
- Can I Use 数据明确标注：IE11 “No support” for nested grid containers
-
@supports (display: grid)在IE11里返回true，但它不支持子级再grid，所以这个检测毫无意义 - 真要兼容，只能用 Flex 做子级布局，或把嵌套结构扁平化为单层Grid + 伪元素模拟分区
