2026年了，flex 一行并排，窄屏时先被挤没的为什么总是文字？

flex 一行并排时窄屏先被挤没的往往是文字，这不是 width 写错，而是两条默认值在起作用：flex-shrink 默认为 1，子项自动最小尺寸又由 min-width: auto 决定。2026 年项目交付里，判断顺序比改属性更重要：先确认父级是不是 flex 容器，再看主轴和压缩比，最后才动宽度。按这个顺序，多数问题能在半小时到两小时的经验区间内定位。

被挤扁的不是 width，是 flex 默认压缩和最小尺寸

在 flex 容器主轴方向，子项尺寸先由 flex-basis、width 和内容尺寸参与计算，空间不足时再由 flex-shrink 分配压缩。默认 flex-shrink: 1 会让所有可压缩子项按比例缩减，所以 width 只是起始尺寸，不是不可变化的尺寸。这也是反复改 width 却看不到变化的原因。

第二层来自 min-width: auto。它表示子项通常不会被压到比自身内容更小。遇到长英文、不可断行文本或固定尺寸图片时，压缩会停在这条内容最小尺寸线上，于是出现两种相反现象：要么怎么压都压不下去，要么文字被压成一列。同一条规则，表现取决于内容能不能断行。

• 前提：父级必须是 display: flex 或 inline-flex，普通块级布局没有这套压缩规则。
• 方向：压缩只发生在主轴，flex-direction: row 时压宽度，column 时压高度。
• 默认值：flex-grow 默认 0、flex-shrink 默认 1、flex-basis 默认 auto、min-width 默认 auto。
• 判断口径：元素变窄但内容完整，说明只是被压缩；内容被裁切或溢出，说明卡在最小尺寸上，改法不同。

按顺序核对：先看容器，再看压缩，最后改落点

方向没定就直接改宽度或加 flex-shrink，常见结果是外层好了、里层又塌，来回改稿。按下面四步走，通常一轮就能收敛。

1. 确认容器与主轴：查看 display 是否 flex、flex-direction 是什么，先排除根本不是 flex 容器。
2. 看子项的 flex 简写：flex: 1 展开是 1 1 0%，基准为 0，容易被压得比内容还小；flex: auto 展开是 1 1 auto，基准取内容尺寸，相对抗压。
3. 区分被压缩还是被内容顶住：前者调 flex-shrink，后者看 min-width 与能否断行，两者不能互换处理。
4. 决定改哪一层：不想被压，就给该子项 flex-shrink: 0 或 flex: none；希望文本截断，才给它 min-width: 0 并配合 overflow 与 text-overflow。

验收可以具体：把容器宽度拉到 320～375px 的常见小屏区间，关键按钮仍完整可见、标题按预期出现省略号、页面不出现横向滚动条，三点同时满足才算处理到位。

三类改法对照：同样被挤，选错会引出新问题

同样是子元素被挤扁，落到代码上常见三类改法，适用对象并不一样。挑改法前先问：容器变窄时，这个元素该跟着变，还是应保持不动。

• flex: none，即 0 0 auto：不放大也不缩小，按 width 或内容宽度走。适合固定宽度侧栏、图标按钮、操作列。代价是空间不足时直接溢出。
• flex-shrink: 0 搭配 width：保留可放大能力，只不允许被压缩。适合头像、开关、状态标签这类不该变形的元素。
• min-width: 0 搭配省略号：允许被压到比内容更小，再配合 overflow: hidden 与 text-overflow: ellipsis 做单行截断。适合标题、地址、用户名等长文本。
• 长英文或 URL：单靠 min-width: 0 不足以断开连续字符，通常还要补 overflow-wrap: break-word 之类的断行处理。

经验区间上，只改一处 min-width: 0 并做小屏验证，常见处理时间是半小时到两小时；如果整行元素都设 flex-shrink: 0，后续排查横向滚动的返工反而更容易拉长到半天以上。判断改得好不好，不看是否写上了属性，而看容器继续变窄时，不该变形的元素是否稳定，允许截断的元素是否稳定出省略号。

交付现场：一处宽度改动，为什么让整行换行

双端 H5 列表项里，结构常是头像、标题、状态标签。设计稿只有 PC 稿，交付约束是安卓低版本 WebView 仍要兼容、设计不能改。当时做法是给标题设 min-width: 0 加省略号，两侧元素设 flex: none。PC 上正常，上线后部分安卓机型上标题被压成一列两个字，状态标签被挤出屏幕，用户看不到当前状态，反馈集中在同一处。最后改成标题 flex: 1 1 auto 并补宽度上限才收敛，多花了半天到一天的经验区间。后来这类项目会把小屏实测直接列为验收项。

返工根因通常不在 API，而在只处理了可见的那一层。几处高频坑供核对：

• 只改子元素 width，不动 flex-shrink，压缩照旧发生。
• 一行里所有子项都加 flex-shrink: 0，容器变窄时整行溢出，出现横向滚动条。
• 写了 text-overflow: ellipsis 却没给 min-width: 0，省略号始终不出现。
• 嵌套 flex 里只改外层，内层容器仍按默认值参与压缩。

适用场景与不适用边界

这套规则适合一行内多个元素需要按比例伸缩、且其中部分元素不能变形的排布，也适合需要单行文本截断的标题或列表项。判断能不能用，先问一句：容器变窄时，谁应该变、谁不应该变，答得出来就适合用 flex 的压缩控制。

反过来说，只有两三个固定尺寸块做简单并排、不需要随容器伸缩的，用 grid 或普通块级布局可读性更好，硬套 flex-shrink 反而增加理解成本。需要展示多行文本的场景也不适合强行做成单行截断，硬压的结果通常是关键信息缺失。

还有一条边界：flex 的压缩规则只作用于 flex 容器的主轴方向。容器不是 flex，或需要压缩的方向落在交叉轴上时，flex-shrink 设成多少都不会有效果，此时要回到容器布局本身判断。

常见问题

为什么子元素写了 width，窄屏还是被压？

因为 width 在 flex 主轴里只是起始尺寸，默认 flex-shrink: 1 会按比例压缩；能不能压到更小，还要看 min-width: auto 这条默认值。

加 min-width: 0 后省略号还是不出现，先查什么？

先查中间嵌套的 flex 层是否也设了 min-width: 0，再确认元素有 overflow: hidden 和 text-overflow: ellipsis，且宽度确实受容器限制。

flex: 1 和 flex: auto 在抗压上差在哪？

flex: 1 展开为 1 1 0%，基准为 0，容易被压得比内容还小；flex: auto 为 1 1 auto，基准取内容尺寸，相对不容易被压瘪。

这套判断对 Grid 布局也适用吗？

不适用。Grid 没有 flex-shrink 这套机制，尺寸由轨道、fr 与 minmax() 决定，需要检查轨道定义和 min-width 设置。

下次再遇到 flex 子元素被挤扁，建议先按四步核对确认规则所在，再决定是加 flex-shrink: 0 还是补 min-width: 0，最后在小屏区间实测横向滚动与省略号。如果布局本身只是几个固定块并排，或需要展示多行文本，继续用 flex 压缩控制反而增加维护成本，换用其他布局方式更省事。涉及多端适配的项目，建议把这条验收项写进交付清单再开工。