Firefox 中 text-overflow: ellipsis 单行失效主因是三件套未同元素配置、overflow: hidden 写在父级、容器为 inline 或无明确宽度、Flex 子项缺 min-width: 0；多行场景下 -webkit-line-clamp 完全不被 Gecko 解析，纯 CSS 无通用方案，需服务端截断、JS 动态计算或视觉模拟降级。
Firefox 不支持 text-overflow: ellipsis 多行方案，也不识别 -webkit-line-clamp —— 它不是“没写对”，而是根本没进渲染引擎。
为什么 text-overflow: ellipsis 在 Firefox 里单行也偶尔不显示？
单行场景下，text-overflow: ellipsis 本身是标准属性，Firefox 支持；但失效往往源于配套条件被破坏：
-
overflow: hidden写在父容器上，而不是文本元素自身 —— Firefox 严格要求三件套（white-space: nowrap、overflow: hidden、text-overflow: ellipsis）必须在同一元素上 - 容器是
display: inline或未设width/max-width，导致宽度计算为auto，浏览器跳过溢出判断 - Flex 子项默认
min-width: auto，即使写了width: 100%也会撑开 —— 必须显式加min-width: 0 - 字体加载延迟或
font-size: 0类样式干扰了渲染时机，省略号生成失败（尤其 SSR + 字体异步加载时）
-webkit-line-clamp 在 Firefox 中完全无效的真相
这不是兼容性“差”，而是语义层面的缺席：-webkit-line-clamp 是 WebKit/Blink 专属私有属性，Gecko（Firefox 内核）从不解析它。你写的整套规则（包括 display: -webkit-box）会被静默丢弃，控制台零报错，调试器里也看不到任何生效痕迹。
- 别试
display: flex+-webkit-line-clamp——display: -webkit-box是硬性前提，flex或grid替代写法一律失效 - 别指望
CSS.supports('-webkit-line-clamp', '2')返回true—— Firefox 下永远是false，这个检测只对 Blink/WebKit 有意义 -
text-overflow: ellipsis在多行场景下本就不该出现 —— 它只响应单行水平溢出，和-webkit-line-clamp共存只是“锦上添花”，不是必需
Firefox 下真正可用的 fallback 方案
没有纯 CSS 的多行省略号，只有务实取舍：
立即学习“前端免费学习笔记（深入）”；
- 服务端截断：按字符数或像素估算提前拼好 “…” —— 稳定、无 JS 开销，但无法响应缩放或字体变化
- JS 动态计算：用
getClientRects()或RangeAPI 测量真实行高与内容高度，再截字符串 —— 注意监听resize和fontload事件，否则滚动中会错位 - 视觉模拟：用
mask-image: linear-gradient(to bottom, black 80%, transparent)遮住底部，配合max-height裁剪 —— 无语义省略号，但布局稳定、全浏览器一致 - 放弃省略号：直接
overflow: hidden+max-height，靠 tooltip 或 hover 展开完整内容 —— 对可访问性更友好，也避开所有兼容陷阱
最容易被忽略的，不是“怎么降级”，而是降级时机 —— 别等页面加载完再 JS 检测支持，应在 HTML 渲染前就决定走哪条路径（比如 SSR 根据 UA 判定是否注入 JS 截断逻辑）。Firefox 用户看到的“省略号”，大概率是后端吐出来的静态字符串，而非浏览器实时计算的结果。
