根本原因是各浏览器对“可压缩空间”的判定逻辑不一致：Chrome按content-box下flex-basis减内容最小宽计算，Firefox将min-width:min-content视为硬下限，Safari iOS甚至忽略min-width:0并重置为min-content。
flex-shrink 计算结果在 Chrome/Firefox/Safari 中为何不同
根本原因不是 flex-shrink 本身有 bug，而是它和 min-width、box-sizing、文字内容宽度三者叠加后，各浏览器对“可压缩空间”的判定逻辑不一致。Chrome 可能按 content-box 下的 flex-basis 减去内容最小宽度来算收缩余量，Firefox 会把 min-width: min-content（尤其是 <button></button>）当作硬性下限，Safari iOS 甚至会忽略你写的 min-width: 0 并偷偷重置为 min-content。
为什么 flex: 1 在 button 上失效，且各浏览器表现不一
因为 flex: 1 是 flex: 1 1 0 的简写，第二个参数 flex-shrink: 1 允许压缩，但浏览器给 <button></button> 默认加了 min-width: min-content —— 这个值在 Chrome 和 Firefox 中可被 min-width: 0 覆盖，在 Safari iOS 15+ 中却会被强制恢复。结果就是：
- Chrome：三个按钮文字长短不一，但都能缩到接近等宽
- Firefox：部分按钮被卡在文字宽度，右侧留白
- iOS Safari：短文字按钮异常窄，长文字按钮又撑得过宽
真正起效的写法是：flex: 1 0 0 + min-width: 0（或 iOS 下改用 min-width: 1px）+ box-sizing: border-box。
如何让 flex-shrink 行为跨浏览器可控
别依赖默认收缩逻辑，显式切断不可控变量：
立即学习“前端免费学习笔记（深入）”；
- 所有参与分配的
<button></button>、<input>、<select></select>必须加min-width: 0；iOS Safari 下若仍不均，换min-width: 1px - 禁用隐式盒模型干扰：
box-sizing: border-box必须显式声明，不能靠 normalize.css 覆盖 - 避免混用
width和flex-basis：后者优先级更高，前者可能被静默忽略 - 固定收缩基准：用
flex: 0 0 200px锁死宽度，或flex: 1 0 0配合min-width: 0实现等分 - 图片/iframe 等替换元素要额外加
flex-shrink: 0，否则 Firefox 会按 intrinsic size 错误压缩
Firefox 下 align-items: stretch 触发基线对齐怎么办
当父容器是 flex-direction: column 或 row，子项含文字、图标、<img alt="CSS flex-shrink在多浏览器渲染计算不一致怎么办？" > 等 inline 元素时，Firefox 会严格按规范执行基线对齐（baseline alignment），而 Chrome/Safari 默认降级为 stretch。这不是 bug，但会导致视觉错位，比如按钮和文字底部不对齐。
- 解法一：统一设
align-items: flex-start或align-items: stretch，避开 baseline - 解法二：对含文字的子项加
align-self: flex-start - 解法三：关键子项加
min-height: 0（垂直布局）或min-width: 0（水平布局），切断基线传播链 - 特别注意：如果子项是
<img alt="CSS flex-shrink在多浏览器渲染计算不一致怎么办？" >，必须加vertical-align: top或display: block，否则基线行为更难控
最易被忽略的是：哪怕你写了 flex-shrink: 0，只要没配 min-width: 0，<button></button> 在 Safari iOS 下依然会按文字内容撑开——这个组合动作缺一不可。
