子元素实际宽度由flex-basis、flex-grow和flex-shrink协同决定：先按flex-basis分配基础尺寸，再按flex-grow在剩余空间中加权分配，或按flex-shrink在溢出时压缩；width仅在flex-basis为auto且flex-grow为0时生效。
flex-basis 和 flex-grow 同时起作用时，子元素宽度怎么算
子元素实际宽度不等于 flex-basis，是因为 flex-grow 在剩余空间里重新分配了尺寸。浏览器先按 flex-basis 分配基础尺寸，再把容器剩余空间（或负向溢出）按 flex-grow 权重重新拉伸 —— 这个过程会覆盖你写的 width 或 flex-basis 值。
-
flex-basis: 200px不是“最终宽度”，只是计算前的起点 - 如果父容器宽
600px，三个子项都设flex: 1 1 200px，初始总和是600px，无剩余空间 → 实际宽度就是200px - 但如果父容器是
700px，剩余100px，三者均分 → 每个变成200px + 33.33px = 233.33px - 若某子项
flex-grow: 2，其余为1，则它拿走剩余空间的 2/4 = 50%，不是简单加固定值
为什么设了 width 还被 flex-basis 覆盖
width 在 Flex 容器中默认不生效，除非显式设置 flex: none 或 flex-basis: auto 且 flex-grow: 0。Flex 布局下，flex-basis 优先级高于 width；当 flex-basis 是具体值（如 150px），它就直接替代 width 成为基准尺寸。
- 写
width: 150px; flex-basis: 200px;→ 最终以200px为基准 - 写
width: 150px; flex-basis: auto;→ 浏览器用width推导flex-basis（即等效于flex-basis: 150px） - 想锁死宽度？用
flex: 0 0 150px（grow=0, shrink=0, basis=150px）
flex-shrink 导致宽度比 flex-basis 还小的常见场景
当子元素内容总宽度超过容器，且 flex-shrink 非零（默认为 1），浏览器会压缩子项，使其小于 flex-basis。这不是 bug，而是 Flex 的收缩机制在起作用 —— 尤其在响应式布局中容易误以为“设了 basis 就不会变”。
- 父容器
width: 400px，两个子项都设flex: 1 1 300px→ 初始需求600px，超容200px - 因
flex-shrink: 1，两者按比例压缩：各减100px→ 实际宽200px - 若其中一个
flex-shrink: 0，它保持300px，另一个被压到100px - 检查是否意外触发收缩？看控制台 computed 样式里的
flex-shrink值
调试 flex 宽度问题的三个关键检查点
别只盯着 width 或 flex-basis 改，真正决定最终尺寸的是三元组协同结果：flex-grow、flex-shrink、flex-basis。chrome DevTools 的 Layout 面板能直观显示“Base size”、“Remaining space”、“Final size”，但得手动展开每个 flex item 才能看到。
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Elements → 选中子元素 → 右侧 Layout 标签 → 展开 “Flex” 区域
- 确认
flex-grow是否为0：非零就会参与剩余空间分配 - 确认
flex-shrink是否为0：非零且内容溢出时必然压缩 - 避免混用
width和flex-basis：统一用flex: 0 0 200px更可控
.container { display: flex; width: 500px; } .item { /* 锁死宽度：不伸展、不收缩、基准 120px */ flex: 0 0 120px; } /* 不要这么写 —— width 和 flex-basis 冲突且不可预测 */ /* .item { width: 120px; flex-basis: 150px; } */Flex 宽度不按预期显示，往往不是某个属性写错了，而是没意识到 flex-grow 和 flex-shrink 在背后持续重算尺寸。哪怕只改一个子项的 flex-grow，整个行的分配逻辑都会变。