flex: 0 0 250px 是左侧定宽唯一可靠写法，因其同时禁用伸缩（flex-grow: 0、flex-shrink: 0）并设基准宽度（flex-basis: 250px），而仅 width: 250px 无法阻止 flex-shrink 默认生效导致压缩。
flex: 0 0 250px 是左侧定宽的唯一可靠写法
只写 width: 250px 在 flex 容器里等于埋雷——哪怕加了 box-sizing: border-box，只要父容器变窄或右栏内容撑开，左栏就可能被压缩。根本原因是 flex-shrink: 1 默认开启，而 flex: 0 0 250px 才真正禁用伸缩：flex-grow: 0、flex-shrink: 0、flex-basis: 250px 三者缺一不可。
常见错误现象：
- 左侧菜单在小屏下突然变窄，文字挤成一团
- 右侧内容区出现横向滚动条，但检查宽度发现“没超”
- 加了
padding: 10px后，右侧直接错位或消失
实操建议：
- 必须搭配
box-sizing: border-box，否则border和padding会额外加宽 - 不要用
min-width: 250px替代，它不阻止收缩，只设下限 - 若需响应式微调（如平板缩小为 200px），用媒体查询改
flex-basis值，别动width
右侧自适应栏不能只靠 flex: 1
flex: 1 确实让右栏填满剩余空间，但它对长单词、URL、表格等“抗收缩内容”完全无感。一旦遇到 https://verylongdomainnamewithoutanydashorstops.com，右栏就会溢出，甚至把整个布局顶出视口。
立即学习“前端免费学习笔记（深入）”；
关键不是“要不要断行”，而是“谁来负责断”。flex: 1 只管分配空间，不管内容怎么折。
实操建议：
- 右栏必须加
min-width: 0，否则 flex 项默认最小宽度是内容长度，会阻止收缩 - 强制断行用
overflow-wrap: break-word（推荐），不是word-break: break-all（会切单词） - 若右栏含
<table>，得额外加table-layout: fixed+width: 100%，否则表格按内容撑宽 - Safari 14–15 对
min-width: 0敏感，漏写就可能导致右侧消失
grid-template-columns: 250px 1fr 比 flex 更干净，但有硬门槛
写 display: grid 不等于自动两列——Grid 默认单列，所有子项全塞进第一列。必须显式写 grid-template-columns: 250px 1fr，其中 1fr 是“剩余空间的一份”，不是百分比，也不受父容器 padding 干扰。
容易踩的坑：
- 写成
250px 100%：第二列会尝试占满整个父容器，直接把左栏挤出视口 - 给右栏加
width: 100%：Grid 子项默认不继承父宽，双重定义导致错位 - 用
gap: 1rem而非margin：加 margin 会破坏轨道计算，间隙必须由gap统一控制
兼容性现实：
- IE 和 Edge ≤15 完全不支持，连前缀都没用
- 若项目需支持 IE10+，降级只能用 flex，不能 fallback 到 float
- 小屏适配可用
grid-template-columns: minmax(250px, 1fr) 1fr，但注意minmax()在安卓 WebView 旧版本中可能失效
calc() 不是新写法，而是兜底方案
width: calc(100% - 250px) 看似简单，实际是语法敏感、嵌套脆弱、无法响应 DOM 变化的静态计算。它只在“父容器 width 明确 + 无 padding/border + 无 transform”的极简场景下才稳定。
典型失效点：
-
calc(100% - 250px)写成calc(100%-250px)（缺空格）→ 浏览器当无效值，退回到 auto - 父容器有
padding: 20px，但没在 calc 中减掉 → 右栏多占 40px - 外层用了
transform: scale(0.9)，创建新包含块 → 100% 指向缩放后容器，计算彻底跑偏
如果真要用 calc()：
- 严格守空格规则：
+/-两侧必须有空格，*//两侧禁止空格 - 统一单位：避免
rem和%混用，优先转成px或用 CSS 变量 - 仅作为兼容 IE11 的降级手段，且必须配合 JS 动态更新变量（如折叠菜单时改
--sidebar-width）
真正卡住布局的，从来不是“怎么写”，而是父容器宽度来源是否明确、内容是否自带抗收缩特性、盒模型是否一致——Flex 和 Grid 都只负责分配空间，不帮你兜底。
