结论：flex-basis本身不决定精准占比，仅设初始尺寸；真正控制最终占比的是flex-grow与是否禁用伸缩。要稳定实现33.33%宽度，须用flex: 0 0 33.33%（禁用伸缩），而非单独flex-basis: 33.33%，并配合box-sizing: border-box、明确父宽及flex-wrap: wrap。
直接说结论：flex-basis 本身不负责“精准占比”，它只管初始尺寸；真正决定最终占比的是 flex-grow 和是否禁用伸缩。想让子项稳定占满 33.33% 宽度，别写 flex-basis: 33.33%，而要用 flex: 0 0 33.33% 或更稳妥的 flex: 0 0 33.3%（IE11 兼容）。
flex-basis 百分比为什么经常“不准”
它计算的是父容器主轴总尺寸（含 padding、border），不是内容区宽度；而且这个计算发生在 flex 分配流程早期——如果父容器宽度还没稳定（比如被 flex 自身撑开、或受 viewport 变化影响），结果就飘。常见现象：
- 横排三项设了
flex-basis: 33.33%，但最后一项换行 - 键盘弹出后导航栏突然错位或挤压
- 同一段 CSS 在 Safari iOS 15.6 上正常，15.5 上全乱
根本原因不是写错了，而是百分比依赖一个「已知且稳定」的父宽，而移动端恰恰最难保证这点。
想要严格等分？用 flex: 0 0 X% 而不是 flex-basis 单独设
flex-basis 单独写 33.33% 时，flex-shrink: 1（默认）仍生效，内容一长或窗口一缩，它就会被压缩，占比立刻失守。必须显式关闭伸缩：
立即学习“前端免费学习笔记（深入）”；
-
flex: 0 0 33.3%→ 等价于flex-grow: 0; flex-shrink: 0; flex-basis: 33.3% - IE11 必须写三值，且建议用一位小数（
33.3%比33.33%更稳） - 配合
box-sizing: border-box，否则padding/border会额外加宽，导致 4 × 25% > 100% - 父容器必须有明确宽度（如
width: 100%或固定像素），不能靠内容撑开
响应式列数切换时，别在媒体查询里反复改 flex-grow
想从桌面端 4 列（flex: 1）切到移动端 2 列（flex: 2），直接改 flex-grow 值容易叠加出错。更可靠的做法是：
- 保持比例逻辑不变，只改基础尺寸：桌面端
flex-basis: 25%，平板端flex-basis: 50%，手机端flex-basis: 100% - 所有断点统一用
flex: 0 0 X%，避免flex-grow干预 - 若需自动换行，父容器加
flex-wrap: wrap，子项用flex-basis: min(100%, 300px)（需配合 CSS 变量或 JS 动态注入，纯 CSS 不支持） - 真要动态调比例，优先用 class 切换（如
.col-3/.col-2），而不是内联 style 或高权重 media query 覆盖
flex-basis: 0% 和 flex-basis: 0px 的实际差异
两者都让项目从零开始分配空间，但兼容性不同：
-
flex-basis: 0%在 IE10/11 中部分版本解析失败，推荐降级为flex-basis: 0px -
flex-basis: 0%更符合语义（百分比上下文），现代浏览器无区别 - 无论选哪个，都必须配
min-width: 0，否则文字或图片可能强制撑开最小宽度，破坏“从零开始”的意图 - 搭配
flex-grow: 1时，flex-basis: 0%+flex-grow: 1才是真正的均分；flex-basis: auto+flex-grow: 1会先按内容算基准，再伸缩，结果不可控
最麻烦的不是语法写对，而是当 flex-basis 设成百分比时，你得同步确认父容器宽度、box-sizing、flex-wrap、甚至嵌套层级里有没有另一个 flex 容器悄悄干扰了主轴尺寸——这些点漏掉一个，占比就偏。
