flex-shrink: 0在firefox中失效，本质是替换元素（如、）受min-width: auto约束，需显式设min-width: 0或改用flex: 0 0 auto，并配合box-sizing: border-box和父容器宽度约束。
不同浏览器对 flex-shrink 的计算差异，本质不是“属性解析不一致”，而是默认行为叠加、盒模型解释不同、以及替换元素（如 <img>、<button></button>）的隐式约束在各引擎中表现不一。直接写 flex-shrink: 0 在 Chrome 看起来生效，在 Firefox 或 iOS Safari 却仍变形，问题通常不出在 flex-shrink 本身。
为什么 flex-shrink: 0 在 Firefox 里像没写一样？
Firefox 严格遵循规范：当子项是 <img> 或 <button></button> 这类替换元素时，即使 flex-shrink: 0 生效，它也只阻止“比例压缩”，但不会绕过浏览器强制施加的 min-width: auto（即最小不能小于内容固有宽度）。结果就是：图片被压到 intrinsic width，但 intrinsic width 在 Firefox 下可能比 Chrome 更“倔”，尤其遇到未设 min-width: 0 时。
实操建议：
- 对所有替换元素显式加
min-width: 0（不是min-width: 1px，后者在 Firefox 下仍可能触发基线对齐干扰） - 避免单独写
flex-shrink: 0，改用flex: 0 0 auto—— 它在 Firefox 中更稳定地锁定基准尺寸，且明确禁用 grow/shrink - 检查父容器是否用了
align-items: stretch（默认值），它会让<img>在交叉轴上强行撑高，视觉上像“被拉伸”，实则是对齐行为，不是flex-shrink计算问题
iOS Safari 对 button 的 min-width 保护怎么绕过？
iOS Safari（15+）给 <button></button> 加了硬编码的 min-width: min-content，连 min-width: 0 !important 都会被忽略。这不是 bug，是 Apple 的可访问性策略 —— 但会导致同为 flex: 1 的按钮在 iPhone 上宽度严重不均。
实操建议：
- 对所有参与 Flex 分配的
<button></button>、<input>、<select></select>显式写min-width: 1px（不是0，也不是auto） - 必须同步加
box-sizing: border-box，否则 padding/border 会额外撑宽，和min-width: 1px叠加后反而更难控 - 别依赖
white-space: nowrap强撑文字宽度 —— 它会让长文本撑破容器，破坏 Flex 均分逻辑
flex-shrink 数值在 Chrome/Firefox/Safari 中真的一样吗？
数值本身解析一致（flex-shrink: 2 就是 2），但最终压缩量取决于三个变量：溢出总量、各子项的 flex-basis（或 width）、以及它们的 flex-shrink × flex-basis 加权值。而 flex-basis 在不同浏览器中受 box-sizing 和伪元素影响极大。
常见坑点：
-
* { box-sizing: border-box }没加在最顶部，被 Normalize.css 覆盖 → 同一个flex-basis: 100px，Chrome 算总宽 100px，Firefox 算成 100px + padding + border - 伪元素（
::before/::after）没继承box-sizing，导致它按content-box计算，悄悄多占空间，让父容器提前溢出 →flex-shrink开始工作，但你根本没意识到伪元素在捣鬼 - 写了
flex: 1又后面补flex-shrink: 0→ 简写已覆盖，后者无效；必须写成flex: 0 0 auto或把flex-shrink: 0放在简写之后并加!important（不推荐）
真正要盯的不是 flex-shrink 值本身，而是 DevTools 里「Layout Width」列的实际像素值，以及「Computed」面板中 flex-basis 解析结果（常显示为 auto 或具体数字）。很多“浏览器差异”，其实是你没看到那个被第三方库悄悄改掉的 box-sizing，或者忘了给 <img> 加 min-width: 0。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
