flex-shrink按「flex-basis×flex-shrink」加权分配溢出空间，而非简单等比收缩；值为0表示不收缩但权重仍计入分母，且受min-width和box-sizing影响。
flex-shrink 不是按数值直接比例收缩，而是用 flex-shrink × flex-basis（或内容宽度）算出“收缩权重”，再按权重分摊总溢出空间。
flex-shrink 的实际计算公式
当容器总宽小于所有子项 flex-basis（或显式 width / 内容宽度）之和时，浏览器会先算出总溢出量，再按每个子项的 flex-shrink × base size 分配收缩量。
具体步骤：
- 取每个子项的“基础尺寸”：优先用
flex-basis值；若为auto，则取其 content width（含 padding、border，但不含 margin） - 计算每项的收缩权重：
flex-shrink× 基础尺寸 - 求所有权重之和：
totalWeight = Σ(flex-shrink × baseSize) - 总需收缩空间：
overflow = Σ(baseSize) − containerWidth - 每项实际收缩量：
(flex-shrink × baseSize) / totalWeight × overflow
为什么不能只看 flex-shrink 数值？
单纯比较 flex-shrink: 2 和 flex-shrink: 1 得不出“前者缩得更多”的结论——如果前者的 flex-basis 是 50px，后者是 300px，那后者的收缩权重反而是 300，远高于前者的 100。
立即学习“前端免费学习笔记（深入）”；
常见误判场景：
- 给图标按钮设
flex-shrink: 0，但没设flex-basis，结果它仍被压缩（因为flex-basis: auto取的是内容宽，可能很小，但其他项权重更大，它“被动让出”空间） - 三个等宽项都设
width: 200px，flex-shrink分别为 1/2/3，但实际收缩量不是 1:2:3，而是按1×200 : 2×200 : 3×200 = 1:2:3—— 这种巧合仅在基础尺寸相同时成立 - 设了
min-width却忽略它：即使权重算出来该缩 80px，若缩完低于min-width，浏览器会截断收缩，导致剩余溢出未被消化，可能触发横向滚动或换行
flex-shrink: 0 的真实效果
flex-shrink: 0 表示“不参与收缩分配”，但它**不等于固定尺寸**：
- 它仍受
flex-basis或width影响；若你没设，它就按内容撑开，而内容本身可能被文本折行、图片缩放等间接压缩 - 它不会阻止父容器用
flex-wrap: wrap把它换到下一行 - 它无法绕过
min-width的底层限制：哪怕flex-shrink: 0，若容器极窄，且子项有min-width: 200px，它依然会溢出或触发滚动
调试时最容易漏掉的点
浏览器 DevTools 的 computed 面板里看不到“收缩后宽度”，只能看到最终渲染尺寸。要验证计算是否符合预期，得手动比对：
- 检查每个子项的
flex-basis计算值（在 Styles 面板里 hoverflex简写属性，或展开flex-basis） - 确认是否被
min-width/max-width截断 —— 收缩量一旦被拦住，整个权重分配逻辑就失效了 - 注意
box-sizing：若设了border-box但flex-basis是content-box行为（如auto），基础尺寸可能比你想象中大
真正卡住布局的，往往不是 flex-shrink 值本身，而是它和 flex-basis、min-width、box-sizing 这三者之间的隐式耦合。
