clip-path配合animation实现逐行显示文字，本质是按换行符切分后对每行独立裁剪动画；需手动包裹span或js拆分，用inset(0 0 y 0)从上往下展开；不支持时可用opacity+delay模拟，但要求每行是独立块级元素。
用 clip-path 配合 animation 实现逐行显示
逐行展示文字，本质是让每一行文字从不可见到可见，按顺序“推”出来。纯靠 line-height 或 height 动画很难精准控制“行”的边界，clip-path 是目前最可控、兼容性够用（Chrome 52+/Firefox 54+/Safari 15.4+）的方案。
关键不是逐字或逐词，而是按换行符（\n 或 HTML 中的 <br>）切分后，对每行做独立裁剪动画。但 CSS 本身不支持按行动态生成 clip 区域，所以得手动为每行包裹 <span></span> 或用 JS 拆分 —— 更推荐后者，避免 HTML 结构污染。
- 手动写 HTML：每行一个
<div> 或 <code><span></span>，配合clip-path: inset(…)从上往下逐步减少遮罩区域 - JS 拆分更灵活：用
textContent.split('\n')得到行数组，动态生成带索引的<span></span>，再给每个设置不同animation-delay -
clip-path: inset(0 0 Y 0)中的Y控制顶部保留高度，从大到小动画即实现“向下展开”效果 - 给每行容器加
opacity: 0和animation: fadeIn 0.3s forwards - 用
animation-delay控制触发时机，如第n行设delay: n * 0.2s - 注意：若使用
<br>换行，它不会产生新元素，此法无效 —— 必须有真实 DOM 节点分隔 - 动画时间不宜过短，否则人眼难以分辨“逐行”，建议单行动画时长 ≥ 0.25s，间隔 ≥ 0.15s
-
letter-spacing动画会让文字“被拽开”，结束时突然回弹，观感生硬 -
scaleX(0)→scaleX(1)会压缩行内所有内容（包括图标、内联元素），且无法与行高解耦 - 如果父容器设置了
overflow: hidden，scaleX缩放可能被意外裁剪，调试困难 - 确认换行来源：是
\n字符、<br>标签，还是 CSS 的white-space: pre-line？不同来源需不同拆分策略 - 检查字体加载：自定义字体未就绪时，
line-height和行高计算不准，clip-pathinset 值会偏移，建议加font-display: swap并监听document.fonts.load - 禁用用户选中干扰：动画过程中若用户双击选中文本，可能中断动画或触发意外 focus，加
user-select: none到动画容器
用 display: block + opacity + animation-delay 模拟逐行
如果目标浏览器不支持 clip-path（比如旧版 Safari），或者内容行数固定、结构可控，可以用“显隐叠加”方式模拟。前提是每行必须是独立块级元素（<div> 或 <code><p></p>），不能是连续文本流中的自然换行。
这种方案不真正“逐行绘制”，而是按顺序淡入已有行，视觉上接近逐行出现，但无法解决单行内文字溢出或截断问题。
为什么不用 letter-spacing 或 transform: scaleX()？
这两种常见思路容易误用：前者拉伸字间距会破坏排版节奏，后者缩放整行会连带影响行高和上下边距，且无法单独控制某几行 —— 它们适合“整段渐显”，不是“逐行推进”。
更隐蔽的问题是，transform 动画在某些移动端 WebKit 内核中可能触发非预期重绘，导致文字闪烁；而 clip-path 的 inset 动画在现代浏览器中由 GPU 加速，性能更稳。
实际部署前必须检查的三件事
逐行动画看似简单，但上线后常因细节翻车。以下三点不验证，大概率在用户侧失效：
逐行动画的复杂点不在代码量，而在对排版上下文的依赖——行高、字体度量、换行逻辑、设备像素比，都可能让同一段 CSS 在不同环境表现不一。动手前先用 getComputedStyle(el).lineHeight 打印实际值，比凭空估算靠谱得多。
