绝大多数现代安卓 WebView 和 iOS Safari 14+ 支持 -webkit-line-clamp，但需同时满足 display: -webkit-box、-webkit-box-orient: vertical、-webkit-line-clamp: N 且 overflow: hidden，缺一则失效；iOS 13 及更早、部分低端安卓系统浏览器不支持，须用 JS 动态检测高度 fallback。
line-clamp在移动端到底支不支持
绝大多数现代安卓 WebView 和 iOS Safari 14+ 都支持 -webkit-line-clamp，但 iOS 13 及更早版本、部分低端安卓机型的系统浏览器（如华为 X86 内核 WebView）会完全忽略该属性——不是截断失效，而是压根不生效，文字照常撑开容器。
关键判断依据不是“有没有加 -webkit- 前缀”，而是是否同时满足：启用了 display: -webkit-box + -webkit-box-orient: vertical + -webkit-line-clamp: N。三者缺一不可，漏一个就退化为普通文本流。
- 仅写
line-clamp: 2（无前缀）在所有当前主流移动端浏览器中均无效 -
overflow: hidden必须显式声明，否则超出行数的文字仍会溢出显示 - 不能和
flex布局混用：display: flex会覆盖display: -webkit-box，导致截断失效
如何让不支持line-clamp的机型安全降级
纯 CSS 无法检测 -webkit-line-clamp 是否生效，所以降级必须靠 JS 主动判断并 fallback。常见错误是只测 UA 或版本号——比如认为 “iOS 13.7 就一定不支持”，但实际某些 iPadOS 13.7 的 WKWebView 已打补丁支持。
更可靠的做法是创建测试节点，动态插入多行文本，对比渲染前后高度：
立即学习“前端免费学习笔记（深入）”；
const testEl = document.createElement('div');
testEl.style.cssText = 'display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; overflow: hidden; width: 100px; height: 0; font-size: 14px;';
testEl.textContent = '一二三四五六七八九十';
document.body.appendChild(testEl);
const clampedHeight = testEl.offsetHeight;
testEl.style.webkitLineClamp = '100';
const fullHeight = testEl.offsetHeight;
document.body.removeChild(testEl);
const supportsLineClamp = clampedHeight < fullHeight * 0.9;如果检测失败，可切换为 JS 截断方案（如按字符数 + textContent + getBoundingClientRect() 动态裁剪），或直接放弃截断，改用省略号 + “展开”按钮交互。
line-clamp与字体、行高、padding的隐性冲突
同一段文字，在不同字体下，-webkit-line-clamp: 2 实际截断位置可能差一行——因为 -webkit-box 的行高计算依赖字体的 line-gap 和 ascent/descent，而这些值在思源黑体、PingFang SC、HarmonyOS Sans 等字体间差异明显。
- 避免用
line-height: 1.5这类相对值，优先用line-height: 20px固定值，确保跨字体行为一致 -
padding会参与容器高度计算，但-webkit-line-clamp只控制内容区行数，若 padding 过大，可能造成视觉上“只显示了一行” - 不要对
line-clamp元素设min-height，它会干扰 WebKit 的行数判定逻辑，导致截断失效
为什么用JS截断比CSS line-clamp更难控制精度
CSS -webkit-line-clamp 是渲染引擎原生实现，能精确到像素级折行；而 JS 截断依赖 textContent + 字符宽度估算或 Range.getClientRects()，在中英文混排、Emoji、变体选择符（如 ??）、连字（ligature）场景下极易误判。
例如 '??'（技术人员 Emoji） 在 iOS 上占两个字符位但只渲染为一个图标，JS 按字符截会提前截断；又如「ffi」（ffi 连字）被当做一个字符，但宽度接近三个字母。
- 不用
String.prototype.slice()直接切字符，优先用Intl.Segmenter（需检查支持）做语言感知分词 - 避免在
resize回调里高频调用getClientRects()，iOS 下易触发强制同步布局，卡顿明显 - 服务端预截断仍是兜底首选：已知最大展示宽度和字体参数时，用 Puppeteer 或 Canvas 测量后返回精简文案
真正麻烦的从来不是“怎么让两行变省略号”，而是“怎么让两行在所有字体、所有缩放比例、所有输入法候选框弹出状态下，都刚好卡在第二行末尾”。这个边界，-webkit-line-clamp 能扛住大部分，JS 很难扛住全部。
