flex: 1 1 auto 的计算起点是内容尺寸而非0，其 flex-basis 为 auto，即按内容宽度、显式 width 或图片固有尺寸确定初始大小，再将剩余空间按 flex-grow 分配；而 flex: 1 等价于 flex: 1 1 0%，起点统一为0，实现严格等分。
flex: 1 1 auto 的计算起点是内容尺寸，不是 0
很多人误以为 flex: 1 1 auto 和 flex: 1 一样会“均分剩余空间”，但关键差异就在 flex-basis：它取值为 auto，意味着每个子项的初始宽度 = 其内容自然宽度（比如文字撑开的宽度、图片固有宽、或显式设置的 width）。这个初始值直接参与后续空间分配计算，不能忽略。
常见错误现象：.itemA 内容长（如 "Dashboard Settings"），.itemB 内容短（如 "X"），容器总宽 600px，结果 A 占 420px、B 占 180px，远非等宽——这不是 bug，是预期行为。
- 如果子项没有内容（空
<div></div>），flex-basis: auto退化为0，此时表现接近flex: 1 - 若子项设置了
width: 200px，则flex-basis: auto会取该width值，而非内容宽度 -
min-width和max-width会在最终宽度上生效，但不改变flex-basis的初始值
剩余空间 = 容器主轴尺寸 − 所有子项 flex-basis 之和
这是整个分配逻辑的算术基础。例如容器 width: 1000px，两个子项分别设 flex: 1 1 auto，内容宽度分别为 350px 和 150px，则：
剩余空间 = 1000 − (350 + 150) = 500px
立即学习“前端免费学习笔记（深入）”；
注意：这个 500px 是真正可被 flex-grow 分配的“纯剩余量”，不是“视觉上看起来还剩多少”。很多开发者用浏览器 DevTools 测量后发现“怎么没填满？”，其实是忘了减去内容本身占的那部分。
- 如果子项内容总宽已超容器（如 1200px），则剩余空间为负数，触发收缩逻辑（
flex-shrink: 1生效） - 百分比类
flex-basis（如50%）按容器当前尺寸计算，但auto不依赖容器尺寸，只看自身内容 - 换行（
flex-wrap: wrap）下，每行独立计算剩余空间，不跨行累加
flex-grow 分配的是“剩余空间”，不是“容器宽度”
flex-grow 的比例只作用于上面算出的剩余空间，而非整个容器宽度。继续上例：剩余 500px，两子项 flex-grow 都为 1，那么各得 250px，最终宽度分别是：
350 + 250 = 600px 和 150 + 250 = 400px
这就是为什么它看起来“不均等”：起点不同，增长量相同，结果必然不同。想强制等宽，必须让起点一致——即把 flex-basis 设为相同固定值或 0%。
- 若一个子项
flex-grow: 2，另一个为1，则 500px 按 2:1 分配（≈333px vs ≈167px），仍基于各自flex-basis叠加 -
flex-shrink在空间不足时也按相同比例反向扣减，但扣减基数仍是各自的flex-basis - 浏览器渲染中，
flex-basis: auto的测量发生在 layout 阶段，受字体、行高、内边距等影响，实际值可能和肉眼估算有偏差
调试时优先检查 flex-basis 实际值，而不是 flex-grow
当布局不符合预期，90% 的问题出在 flex-basis 被隐式影响。DevTools 的 computed 标签页里，展开 flex-basis 项，看它显示的是具体像素值（如 124.33px）、auto 还是 0%。不要只盯着 flex 简写声明。
容易被忽略的点：white-space: nowrap 会让文本不折行，大幅拉高 flex-basis；而 overflow: hidden 或 text-overflow: ellipsis 不影响 flex-basis 计算，只影响渲染。
- 临时验证可用
flex-basis: 0px强制归零起点，观察是否回归等分预期 - 用
border或outline包裹子项，配合 DevTools 的 layout 边框，直观对比内容宽与最终宽的差值 - 避免在子项上同时设
width和flex-basis: auto，除非你明确知道 width 会被后者覆盖（且仅当 width 为非 auto 时）
