flex-shrink 为 0 时元素不压缩；其默认值为 1，易致移动端子项在空间不足时被意外压缩，引发错位；应针对固定尺寸项显式设 flex-shrink: 0，并配合 min-width 和 flex-basis 合理使用。
flex-shrink 为 0 时元素不压缩，但很多人误设成 1 导致错位
移动端 Flex 布局错位，常见原因是子项在空间不足时被意外压缩——flex-shrink 默认值是 1，意味着所有子项按比例“让出”空间。一旦父容器宽度受限（比如 max-width: 100% 或嵌套在 position: fixed 容器中），文字多、图片宽或带 padding 的项就会被强行压扁，出现文字换行、图标变形、按钮截断等现象。
实操建议：
- 明确需要固定尺寸的项（如图标按钮、头像、徽标），直接设
flex-shrink: 0 - 避免全局重置
* { flex-shrink: 0 }，这会破坏正常流式行为 - 注意
flex-shrink不接受负值，设成-1会被浏览器忽略并回退到 1 - 搭配
min-width使用更稳妥，例如：min-width: 44px（满足移动端最小点击区域）
flex-shrink 数值不是“权重”，而是“压缩难易度”的倒数
flex-shrink 的计算逻辑常被误解：它不是按数值占比分配压缩量，而是先按 flex-basis（或 width）算出“溢出总量”，再按 shrink * basis 加权分摊压缩量。也就是说，flex-shrink: 2 的项，比 flex-shrink: 1 的项“更容易被压”，且压缩量接近两倍。
典型场景：
立即学习“前端免费学习笔记（深入）”；
- 一行三个按钮，中间按钮文字较长，希望它少压缩、两边图标按钮多压缩 → 中间设
flex-shrink: 0，两边设flex-shrink: 2 - 搜索栏含输入框 + 按钮，输入框应撑满剩余空间，按钮保持固定宽 → 输入框用
flex: 1（等价于flex-grow: 1; flex-shrink: 1; flex-basis: 0），按钮加flex-shrink: 0 - 使用
flex: 0 0 auto可同时禁用伸缩，比单独写flex-shrink: 0更清晰
和 flex-basis、width 冲突时，flex-shrink 表现不可预测
当子项同时设置了 width、flex-basis 和 flex-shrink，浏览器会优先采用 flex-basis（除非为 auto），而 width 仅在 flex-basis: auto 时作为后备。此时若 flex-basis 过大，flex-shrink 就得承担全部压缩任务，但压缩结果受盒模型影响（padding/border 是否包含在内）。
容易踩的坑：
- 用了
box-sizing: border-box却忘了flex-basis仍按 content-box 计算（除非显式设为flex-basis: 100px） -
flex-basis: auto+width: 120px在某些 Android WebView 中表现不一致，建议统一用flex-basis: 120px - 文字内容动态变化时（如 i18n 多语言），
flex-basis固定值可能失效，此时更适合用min-width+flex-shrink: 0
真机测试时，iOS Safari 和微信内置浏览器对 flex-shrink 处理有差异
iOS 15+ Safari 对 flex-shrink 的计算更严格，尤其在 display: flex 容器嵌套 position: absolute 子项时，可能完全忽略 flex-shrink；而微信 iOS 客户端（X5 内核）存在 flex 压缩后未触发重绘的问题，导致视觉上“卡在压缩态”。
应对方式：
- 在关键节点加
transform: translateZ(0)强制硬件加速，触发重排 - 避免在
flex-shrink: 0元素上同时用white-space: nowrap+ 长文本，iOS 下可能溢出容器却不换行 - 用
@supports (display: flex) and (flex-shrink: 1)做特性检测，降级方案用width: calc(...)手动计算
实际项目里，错位往往不是单一属性问题，flex-shrink 是开关，但真正起效依赖 flex-basis 的初始值、父容器约束强度、以及是否触发了浏览器的 flex 重排 bug。调试时优先检查 computed styles 中的 flex-shrink 是否生效，而不是只看声明值。
