-webkit-line-clamp在Firefox中完全不生效，因为它是WebKit私有属性，Firefox基于Gecko引擎根本不解析该声明；Chrome、Safari等能运行是因同源而非标准支持。
为什么-webkit-line-clamp在Firefox里完全不生效
因为它是WebKit内核的私有属性，Firefox用的是Gecko引擎，压根不解析-webkit-line-clamp、display: -webkit-box这些声明。你写得再全，DevTools里也看不到对应计算值——不是bug，是根本没加载。Chrome、Safari、Edge（Chromium版）能跑，纯属“恰好同源”，不是CSS标准。
overflow: hidden写了但省略号还是不出现的常见原因
多行截断依赖视觉溢出判定，而不仅仅是样式声明。以下情况会让浏览器认为“没溢出”，导致-webkit-line-clamp静默失效：
- 父容器是
display: flex子项，且没加min-w-0或flex: 1，文字强行撑宽，scrollWidth === offsetWidth - 元素本身是
inline（比如<span>），没转成display: inline-block或block，宽度约束无效 - 用了
<td>，默认display: table-cell，text-overflow和-webkit-line-clamp均不触发 -
max-height设得太小（比如只写了line-height * 2），最后一行被裁掉但没留出省略号空间
移动端iOS Safari中省略号消失的真正原因
iOS 16.4+之后，Safari对-webkit-line-clamp的渲染逻辑收紧：如果容器font-size动态变化（如响应式rem/vw）、或父级用了transform、will-change，WebKit会跳过行数计算，直接显示全文。这不是缓存问题，是渲染管线主动降级。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 避免在省略容器上直接写
font-size: clamp(...)，改用固定em或px - 别给父级加
transform: translateZ(0)这类强制硬件加速的hack - 用
getComputedStyle(el).lineClamp检测是否被忽略（返回''说明已失效）
想兼容Firefox，JS降级不是万能解药
很多方案推荐用scrollHeight > clientHeight判断溢出再截字符串，但实际踩坑点密集：
- 中英文混排时，
textContent.length和视觉行数严重不匹配（一个中文=两个英文字符宽度） - 动态内容（比如Vue响应式字段）触发重排后，
clientHeight可能还没更新，导致误判 - 表格单元格、Flex子项里调用
getBoundingClientRect()，结果受父级overflow影响，返回0 - 滚动中频繁调用测量函数，帧率直接掉到20fps以下
更稳妥的做法是服务端按字体、字号、宽度预估字数截断，前端只做兜底渲染——省略号语义不在前端生成，而在数据层就确定。
