flex-grow按剩余空间×权重分配而非百分比，需显式设flex-basis:0（如flex:1 1 0）避免auto导致内容依赖；混用width与flex-grow易布局断裂；IE11存在计算偏差，应规避精确控制。
flex-grow 计算结果和百分比不一致？别信直觉，看浏览器怎么算
Flex 容器里设 flex-grow: 1 和 width: 33.33% 看似等效，实际布局常错位——根本原因是 flex-grow 不按百分比分配空间，而是按「剩余可用空间 × 权重比例」再减去元素自身基础尺寸后分配。
比如三个子项都设 flex-grow: 1，但其中一项有 min-width: 200px，另一项内容撑开到 150px，那它们实际占宽就不是 1/3，而是：先扣掉所有子项的 flex-basis（默认为 auto，即内容宽度），再把剩下的空间三等分，最后加回去。
- 用
flex-grow前，务必显式设flex-basis（如flex: 1 1 0），否则auto会引入不可控的内容依赖 - 想严格按百分比控制，直接用
width+flex-shrink: 0，但注意这会禁用收缩，可能溢出容器 -
flex-grow的值只是权重比，flex-grow: 2和flex-grow: 4效果等同于1和2，别盲目堆数字
flex-basis 设成 0 还是 auto？影响空间是否计入初始尺寸
flex-basis 是 flex-grow 计算的起点。设成 0（如 flex: 1 1 0）意味着“忽略内容宽度，从零开始分剩余空间”；设成 auto（默认）则先按内容宽占位，再分剩余空间——后者才是多数人踩坑的源头。
常见错误现象：flex-grow: 1 的卡片文字多时变宽、文字少时变窄，看似响应式，实则是 flex-basis: auto 在捣鬼。
立即学习“前端免费学习笔记（深入）”；
- 要均分容器宽度，统一写
flex: 1 1 0，别省略第三个参数 - 如果子项有固定最小宽度需求，用
min-width配合flex-basis: 0，而不是靠flex-basis: auto撑开 - Chrome DevTools 里检查元素的「Computed」面板，重点看
flex-basis实际解析值，不是你写的值
百分比 width 和 flex-grow 混用导致布局断裂
在同一个 Flex 容器里，有的子项写 width: 25%，有的写 flex-grow: 1，结果往往失控——因为 width 是绝对尺寸声明，而 flex-grow 是弹性分配逻辑，两者在 layout 阶段的介入时机和优先级不同。
典型报错没有，但表现是：小屏幕下某列突然换行、间隙忽大忽小、border 错位。
- 全容器统一策略：要么全用
flex-grow+flex-basis: 0，要么全用width+flex-shrink: 0 - 真需要混合（如侧边栏固定宽 + 主区自适应），用
flex: 0 0 200px（不伸缩不收缩）配flex: 1 1 0，别混width - 媒体查询中改
flex-grow比改width更安全，因为不触发重排（reflow）
IE11 下 flex-grow 计算偏差大，别依赖它做像素级对齐
IE11 的 Flex 实现有已知 bug：当 flex-basis 为 0 且存在 border/padding 时，flex-grow 分配的空间会少算这些值，导致总宽度不足容器宽，出现诡异空隙或滚动条。
这不是你代码写错了，是引擎缺陷。DevTools 里看 computed width，IE11 显示的数值和 Chrome 差几个像素很常见。
- 兼容 IE11 时，给 flex 容器加
box-sizing: border-box，并确保所有子项也设该属性 - 避免在 IE11 中用
flex-grow控制带border或padding的精确列宽，改用width+calc() - 用
@supports (display: flex)包裹现代写法，IE11 自动 fallback 到 float 或 table 布局
flex 时，下意识问一句：这个 flex-basis 到底被解析成什么了。 
