SCSS @mixin 无法实现真正跨浏览器多行截断，仅能封装 -webkit-line-clamp 等已有方案并分层降级；Firefox/IE 不支持该属性，硬用 text-overflow: ellipsis 于多行会失效，根本因底层机制不统一且 SCSS 无运行时检测能力。
直接说结论：SCSS @mixin 无法实现真正“跨浏览器”的多行截断，它只能封装已知有效方案（如 -webkit-line-clamp）并做兼容性分层处理；Firefox 和旧版 Edge 中必须接受降级（不截断或靠 max-height 粗略裁剪），硬塞 text-overflow: ellipsis 到多行上会完全失效。
为什么不能只用一个 @mixin 覆盖所有浏览器
根本原因在于：CSS 多行截断依赖的底层机制在各浏览器中不统一。-webkit-line-clamp 是 WebKit/Blink 私有属性，Firefox 直到 68+ 才通过实验性 flag 支持（且默认关闭），IE 完全不识别。SCSS 是编译时工具，它不能运行时检测浏览器能力，更不能生成条件逻辑来“切换”不同方案——它只能输出你写死的 CSS 规则。
所以 @mixin 的真实作用是：把一组强耦合、易漏写的声明打包复用，并通过 @supports 或注释明确标出适用边界。
- 漏掉
display: -webkit-box→ 截断无效 - 漏掉
-webkit-box-orient: vertical→ 行数限制不生效 - 写了
text-overflow: ellipsis但没配overflow: hidden→ 省略号不显示 - 在 flex 容器子项里直接用 → 可能因
min-width: auto导致宽度撑开、截断失败
@mixin truncate-lines($lines: 2) 的标准写法
这个 mixin 必须包含三类内容：核心 WebKit 声明、@supports 包裹、以及 fallback 回退样式（非 JS 方案下能做的极限）。
立即学习“前端免费学习笔记（深入）”；
@mixin truncate-lines($lines: 2) {
// 基础 fallback：靠 max-height + line-height 粗略控制高度
line-height: 1.4em;
max-height: $lines * 1.4em;
overflow: hidden;
<p>// 仅在支持 -webkit-line-clamp 的浏览器中启用精确截断
@supports (-webkit-line-clamp: 1) {
display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: $lines;
overflow: hidden;
text-overflow: ellipsis;
max-height: none; // 覆盖上面的 max-height，避免双重限制
}
}调用时必须确保父容器有明确宽度（如 width 或 max-width），否则 -webkit-line-clamp 无法计算换行位置；同时避免和 text-align: justify 共用，WebKit 下省略号可能错位。
Firefox 和 IE 的实际处理策略
不要试图用 SCSS “骗过” Firefox —— 它不解析 -webkit- 前缀，也不支持 line-clamp 标准语法（即使现在部分版本开启 flag，也不能假设用户已启用）。正确做法是接受视觉降级：
- 对 Firefox 用户：保持
max-heightfallback，文字被硬裁剪，无省略号，但布局不破 - 对 IE11 及更早：完全忽略
@supports块，只保留max-height+overflow: hidden，此时需手动测试行高是否匹配字体渲染（如 Windows 上微软雅黑 vs macOS 上 San Francisco 高度差异） - 若业务强制要求所有浏览器都显示省略号，
@mixin就不该是首选——该换 JS 方案（如clamp.js或自研文本测量逻辑）
容易被忽略的关键细节
很多人抄完 mixin 就以为万事大吉，但实际部署时高频翻车点就藏在细节里：
-
line-height必须是数值单位（1.4），不能是px/em绝对值，否则响应式缩放时max-height计算失准 - 如果容器用了
font-size: clamp(...)，max-heightfallback 需同步用clamp()计算，否则小屏下文字被多裁 1 行 -
@supports (-webkit-line-clamp: 1)检测的是属性存在性，不是行为一致性 —— Safari 15.4 曾有-webkit-line-clamp生效但省略号偏移的 bug，得靠额外padding-bottom: 0.1em微调 - SSR 渲染时，服务端无法执行
@supports，所以生成的 CSS 包含全部规则；客户端加载后由浏览器自行丢弃不支持的部分 —— 这没问题，但别误以为服务端能“预判”兼容性
真正难的不是写出那个 mixin，而是清楚知道它在哪生效、在哪静默失效、以及失效后用户看到什么——这些决定了你是否需要补 JS、是否要加“查看更多”按钮、甚至是否该改文案长度规范。
