最简且最稳的写法是grid-template-columns: 240px 1fr，它使侧边栏固定240px、主内容占满剩余空间；常见错误包括用auto或%混用、冗余minmax；主内容撑不满高度需检查高度链路；滚动异常需给主内容设overflow-y: auto和高度约束；fr分配的是扣除gap和min-content后的剩余空间。
用 grid-template-columns 配合 minmax() 和 fr 控制基础弹性分栏
直接写死像素宽度（比如 240px 1fr）只能固定一端，真要“可调整”，得让列宽具备最小/最大边界 + 弹性分配能力。核心是把 minmax(min, max) 和 fr 结合进 grid-template-columns。
常见错误是只写 1fr 1fr——这确实等宽，但用户没法拖拽；或者写 200px 1fr——左侧锁死，右侧被动填满，仍不算“可调整”。
-
minmax(200px, 1fr)表示该列至少 200px，最多拿走 1 份剩余空间（不是固定比例，而是上限弹性） - 多个列都用
minmax()时，fr部分会按权重分配剩余空间，比如minmax(200px, 1fr) minmax(200px, 2fr)，右边列在空间充足时会比左边宽一倍 - 不要混用
px和fr做“比例计算”：像100px 1fr 2fr是合法的，但1fr 2fr 300px中的300px会先占位，剩下的才由1fr和2fr分——这点容易误判实际宽度
拖拽调整宽度必须靠 JavaScript，CSS 只能模拟“视觉可缩放”
CSS 本身没有“拖拽分隔线”能力。所谓“可调整”，实际分两层：一是视觉上让用户感知某栏能缩放（比如加 resize），二是真正改变列宽（必须 JS 修改 grid-template-columns 的值）。
纯 CSS 模拟仅适用于后台工具类界面，且有严格限制：
- 给侧边栏容器设
resize: horizontal，但必须同时设overflow: auto或hidden，否则无效 - 该容器需是块级元素、有明确 width（不能是
1fr直接撑满）、且父容器为display: grid—— 否则 resize 手柄不出现 - resize 改变的是该元素自身的
width，而 Grid 列宽是整体定义的，所以实际效果只是“内容区被挤压”，列轨道并未重算；真正的响应需监听resize事件并动态更新style.gridTemplateColumns
响应式切换比强行“全程可调”更实用
多数真实场景中，用户并不需要每屏都拖拽——小屏收起侧边栏、中屏双栏、大屏三栏，才是合理路径。硬推“全尺寸可拖拽”反而增加复杂度和兼容风险。
- 用媒体查询切布局比用 JS 监听 resize 更稳定：
@media (max-width: 768px) { .container { grid-template-columns: 1fr; } } - 注意：断点别只盯视口宽度。嵌入 iframe、侧边栏展开后容器变窄等情况，
@container查询更准，但目前仅 Chrome/Firefox 支持，Safari 仍需降级为 ResizeObserver + class 切换 - IE 完全不支持
fr单位，哪怕加了display: -ms-grid也无效，必须 fallback 到float或flex，且不能依赖gap（得用margin模拟）
fr 单位不是百分比，别在子项上乱设 width
很多人写完 grid-template-columns: 1fr 2fr，又给子元素加 width: 50%，结果布局错乱——因为 fr 是 Grid 容器内部分配逻辑，子项的 width 会覆盖 Grid 的列轨道约束。
-
fr不等于100%：它分的是“容器减去所有固定尺寸后的剩余空间”，不是整个容器宽度 -
fr也不等于auto：auto会让列收缩内容，1fr保证至少占一份弹性空间 - 子项上设
width、flex、float都会干扰 Grid 布局，除非你明确想脱离轨道控制（比如局部用 flex 排子元素）
真正可控的“可调整”，是明确哪几列允许缩放、缩放到什么边界、在什么设备上启用——而不是堆砌所有弹性单位然后指望自动适配。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
