flex-basis 是初始主轴尺寸而非 width，受 flex-grow/shrink 影响；设 flex: 0 0 200px 才锁死宽度，百分比需父容器有 width，响应式推荐 min-width + flex-wrap + flex: 1 1 auto。
flex-basis 不是 width，但常被当 width 用
很多人写 flex-basis: 200px 后发现元素不按预期缩放，是因为它只在 flex 容器中起“初始主轴尺寸”作用，后续仍受 flex-grow 和 flex-shrink 影响。比如设了 flex: 1，flex-basis 就会被忽略；设 flex: 0 0 200px 才真正锁死宽度。
常见错误现象：flex-basis: 50% 在子元素上没效果？那是因为父容器没设 width，百分比无参照；而 flex-basis: 50vw 或具体像素值就没这个问题。
- 响应式栅格中，优先用
flex-basis+flex-grow: 0+flex-shrink: 0组合来固定列宽（如侧边栏） - 需要弹性伸缩的列，改用
flex: 1或flex: 2，此时flex-basis应设为0（避免内容撑开导致比例失准） -
flex-basis: auto会先测量内容尺寸再参与分配，适合文字卡片类布局，但可能引发换行或溢出
用 flex-wrap + min-width 实现“流式断行栅格”
纯 flex 单行布局没法自动折行，一卡就全挤乱。真正可用的响应式栅格，得靠 flex-wrap: wrap 配合子项的 min-width 控制断点。
使用场景：商品列表、卡片网格、仪表盘小组件——内容宽度不固定，但希望每行尽可能塞满 3–4 个。
- 给容器加
display: flex和flex-wrap: wrap - 给子项设
flex-basis: 300px（或min-width: 300px），同时配flex: 1 1 auto，让它们能伸也能缩 - 别只靠媒体查询调
flex-basis，那样维护成本高；用min-width+flex-wrap更自然 - 注意 Safari 旧版本对
flex-basis: 0%渲染异常，统一用像素或vw更稳
flex-grow 超出父容器时的“负空间”陷阱
当多个子项都设 flex-grow: 1，但总内容宽度超过父容器，它们会按比例压缩——但压缩不是无限的。一旦某个子项内部有不可缩内容（比如图片、white-space: nowrap 文字），就会撑破布局，甚至触发横向滚动条。
错误现象：flex: 1 的卡片里放了长链接，整行错位或溢出；调试时看到 computed styles 中 flex-basis 是 0，但实际尺寸远大于 0。
- 给关键子元素加
min-width: 0（尤其是含文本/图片的容器），允许 flex 真正收缩 - 图片记得加
max-width: 100%和height: auto，否则破坏 flex 计算 - 用
overflow: hidden+text-overflow: ellipsis处理超长文本，比依赖 flex 收缩更可靠
IE11 下 flex-basis 百分比失效的兼容方案
IE11 对 flex-basis: 33.333% 解析不稳定，尤其嵌套 flex 容器时，经常回退成 auto，导致栅格列宽崩塌。这不是 bug，是标准实现差异。
性能影响不大，但兼容性代价高——不能靠 polyfill 修复，必须降级写法。
- 放弃百分比，改用具体像素值（如
flex-basis: 240px）+ 媒体查询分段控制 - 或者直接切到
display: table-cell降级方案（仅限两列/三列等简单场景） - 如果项目已用 CSS-in-JS，可在 JS 层判断
document.documentMode，动态注入 IE 专用 class - 别指望
flex: 0 0 calc(100% / 3)在 IE11 工作——calc()在 flex-basis 中不被支持
flex 栅格真正的复杂点不在语法，而在内容可变性与容器约束之间的拉扯。你永远要问一句：这个卡片里的图片最大能多宽？那段标题最长几个字？这些才是决定 flex-basis 和 min-width 该怎么写的依据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
