-webkit-line-clamp仅Webkit内核支持，需display:-webkit-box和-webkit-box-orient:vertical配合；Firefox用标准line-clamp但机制不同，省略号易失效，应以max-height+overflow:hidden为回退方案。
因为 -webkit-line-clamp 是 WebKit 专属实现，而 Firefox 的 line-clamp 标准属性不复用同一套渲染逻辑，两者对“行高计算”“省略号插入时机”“文本基线对齐”的处理存在底层差异。
WebKit（Chrome/Safari/Edge）的省略号位置逻辑
它依赖 display: -webkit-box + -webkit-box-orient: vertical 构建一个垂直弹性容器，-webkit-line-clamp 实际上是在这个盒子内部做“行数计数+最后一行末尾截断+强制加 text-overflow: ellipsis”。关键点：
- 省略号一定出现在第 N 行的最右端，哪怕该行实际只占用了半行宽度
- 行高必须是确定值（如
1.4em），line-height: normal或百分比会导致截断错位 - 如果父元素有
transform或will-change: transform，iOS Safari 15.4–16.3 会漏掉省略号甚至少截一行
Firefox 的 line-clamp 不走 WebKit 渲染路径
Firefox 68+ 支持无前缀的 line-clamp: 3，但它不是基于 -webkit-box，而是走标准 CSS 布局引擎（Gecko）的行盒（line box）截断机制。这意味着：
- 它不强制要求
display: block或其他 display 值，但也不支持text-overflow: ellipsis自动生效 - 省略号是否显示、在哪显示，取决于当前行盒的
text-overflow是否被继承、以及该行盒是否“可截断”（比如是否含 inline-level 元素） - 更常见的情况是：省略号根本不出现在末尾，或者只在第二行末尾出现，第三行直接被物理裁切（无省略号）
为什么不能靠 @supports (line-clamp: 1) 检测？
这个媒体查询在所有浏览器里都返回 false，因为 line-clamp 属于 overflow 相关属性，而 @supports 对这类属性的支持检测不可靠。真正可用的是：
立即学习“前端免费学习笔记（深入）”；
-
getComputedStyle(el).webkitLineClamp !== undefined→ 判定 WebKit 支持 -
'lineClamp' in document.documentElement.style→ Firefox 有时能返回 true，但不稳定 - 更稳妥的做法：先写 WebKit 方案，再用
@supports (-webkit-line-clamp: 1)包裹，然后单独给 Firefox 加max-height回退
Tailwind 或带内边距的场景下省略号“偏移”
当 line-clamp-2 和 py-2 同时作用于同一个 <div> 时，问题不是“省略号位置不同”，而是“省略号根本没机会正确计算”：
<ul>
<li>
<code>py-2 增加了 padding-top/padding-bottom，但 -webkit-line-clamp 只在 content area 内计行
line-clamp 类单独用在子容器上（比如 <div class="line-clamp-2">
<p class="py-2">...），避免 padding 干扰截断计算
</p>
<p>真正难调的不是写法，而是当 <code>font-size 动态变化、中英文混排、又开了 transform 时，WebKit 渲染层会临时丢失剪裁上下文——这时候连 backface-visibility: hidden 都不一定救得回来，得切回 max-height + overflow: hidden 物理截断。
