auto-fit 更适合仪表盘卡片，因其收缩空轨道使列宽自适应，避免小屏下出现极窄列导致文字换行、触控失效；auto-fill 则保留所有轨道易引发布局错位。
为什么 auto-fit 比 auto-fill 更适合仪表盘卡片
仪表盘卡片必须在小屏下保持可读、可点、不变形，auto-fit 是默认更安全的选择：auto-fit 会把空轨道收缩掉，把省下的空间分给有内容的列；而 auto-fill 会强行保留所有可能轨道，导致小屏下出现极窄列——文字挤成两行、图标热区缩到手指点不中、卡片内部布局错位。
-
auto-fit：容器宽 720px，minmax(280px, 1fr)→ 最多塞 2 列（2×280 = 560 ≤ 720），空轨道归零，2 列均分剩余宽度 -
auto-fill：同样 720px，它仍会尝试生成第 3 轨道（3×280 = 840 > 720），但因放不下，该轨道宽度塌为 0，却仍参与布局计算，易引发渲染抖动或 margin/gap 错位 - 别混用：
repeat(auto-fill, 1fr)或repeat(auto-fit, 300px)都是无效写法——minmax()不可省略，否则浏览器无法判断“一列至少多宽”
minmax(280px, 1fr) 中的 280px 怎么定
这不是凭感觉写的数字，而是实测底线：含 padding、border、最小字号（14px）、触控目标（≥44px 高）后，文字仍能单行显示、按钮可点击、图表坐标轴不被裁切。
- 设成
200px：iPhone SE 屏宽 375px，gap: 1rem（≈16px）占掉 32px，剩 343px → 2 列 × 200px + 16px gap = 416px > 343px，被迫退为 1 列，但卡片内文字频繁换行，行高失控 - 设成
350px：iPad 竖屏 768px 宽，gap: 1rem × 1 = 16px → (2×350)+16 = 716px ≤ 768px，刚好 2 列；但 (3×350)+32 = 1082px > 768px，无法上 3 列，白白浪费横向空间 - 280px 是平衡点：768px 下可塞 2 列（2×280+16=576），也能在 920px 左右自然上 3 列（3×280+32=872），过渡平滑
侧边栏和主卡片区必须解耦
把侧边栏硬塞进 repeat() 里，等于让它和卡片一起参与列数动态计算——结果是导航菜单文字被压缩成“…”，图标错位，折叠按钮点不中。
- 外层用
grid-template-areas显式划分：“header header” “nav main” “nav footer”，nav区域设grid-area: nav -
nav的宽度单独控制：grid-template-columns: 240px 1fr，不带minmax()，不参与auto-fit - 主内容区（
.main）再嵌套一层 Grid，里面才写grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)) - 检查 computed 样式：确保
.main的display确实是grid，不是被父级flex或inline覆盖
移动端 grid-template-areas 失效的三个真因
写了 "header" "nav" "main" 却横着排，不是语法错，而是 Grid 根本没启用。Safari 和 Chrome 移动版对缺失声明极其敏感。
- 每个媒体查询里必须同时重写四样：
display: grid、grid-template-areas、grid-template-columns、grid-template-rows—— 缺一不可 - 别只改
grid-template-areas，例如从"header nav main"改成"header" "nav" "main"，但grid-template-columns还卡在1fr 240px 1fr，浏览器直接忽略整条规则 - 用浏览器 devtools 的 “Computed” 面板查最终生效的
display值，不是看 Styles 面板有没有写，而是确认它真是grid
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
