直接用@keyframes写打字机动画卡在“字符数不确定”是因为Sass编译期静态，无法预知动态文本长度；可行方案是Sass根据字符数反推动画时长与关键帧比例，用@for生成opacity阶梯式显隐，配合overflow:hidden和white-space:nowrap确保效果。
为什么直接用 @keyframes 写打字机动画会卡在“字符数不确定”上
常见做法是写死 width: 0 → width: 100% 或逐帧定义每个字符的 opacity，但一旦文本内容动态生成（比如从 CMS 拉取、或由 JS 注入），就无法预知字符长度，@keyframes 里没法用 Sass 变量插值做动态帧数。Sass 编译期静态，运行时才知字符串有多长——这是根本矛盾。
真正可行的路径只有一条：把「逐字符偏移」逻辑交给 CSS 自身计算，Sass 只负责生成适配不同长度的 animation-duration 和关键帧比例。核心不是“让 Sass 算偏移”，而是“让 Sass 根据字符数反推动画节奏”。
实操建议：
- 用
str-length($text)获取字符数，注意它对空格、换行符都计数，若需过滤，先用str-replace清理 - 动画总时长建议按
$char-count * 0.12s设定（0.12s/字符是肉眼舒适阈值，太快易闪，太慢显拖沓） - 避免用
ch单位做width动画——等宽字体才准，且 Safari 对ch的animation支持不稳定
用 string.slice() + @for 生成逐字符 opacity 关键帧
Sass 本身不支持运行时字符串切片，但编译期可以模拟「逐字符显隐」：对长度为 $n 的文本，生成 n 个 @keyframes 帧点，每帧让前 i 个字符 opacity: 1，其余为 0。关键不是真切字符串，而是按索引控制透明度阶梯。
立即学习“前端免费学习笔记（深入）”；
示例（假设文本长 5 字）：
@keyframes typewriter {
0% { opacity: 0; }
20% { opacity: 1; } // 第1字出现
40% { opacity: 1; } // 第2字出现
60% { opacity: 1; } // 第3字出现
80% { opacity: 1; } // 第4字出现
100% { opacity: 1; } // 第5字出现
}实操要点：
- 用
@for $i from 1 through $char-count循环，计算每帧百分比：#{percentage($i / $char-count)} - 必须给容器设
overflow: hidden，否则未显示字符仍占位，造成布局跳动 - 别忘了加
white-space: nowrap，防止长单词换行打断动画流
font-family 差异会让 ch 和 em 偏移完全失准
很多人想用 width: calc(#{$i}ch) 实现字符级宽度展开，但 ch 是“数字 0 的宽度”，非等宽字体下每个字符实际像素宽度不同（比如 i 比 w 窄很多），导致光标停顿位置错乱。Sass 无法在编译期知道当前 font-family 下每个字符的真实宽度。
更稳的替代方案：
- 用
border-right模拟光标：固定1px solid，靠animation-delay错开闪烁时机，和文字显隐解耦 - 若坚持宽度动画，改用
max-width+inline-block包裹单字符，但需 JS 预处理 DOM 结构——这已超出纯 Sass 范畴 - 测试阶段务必在目标字体（如 Inter、SF Pro）下实测，不能只看浏览器默认
sans-serif
最终输出的 CSS 必须兼容 will-change: opacity 提升
逐字符 opacity 动画在低端设备上容易掉帧，尤其当页面有其他动画同时运行时。Sass 生成的代码里要主动插入 will-change: opacity，但仅对动画元素生效，避免全局滥用拖慢渲染。
注意点：
- 不要写
will-change: transform——这里没用到transform，瞎加反而触发多余图层合成 - 动画结束后记得用
animation-fill-mode: forwards锁定最终态，否则opacity会回退到初始值 - 如果文本含图标（
::before伪元素），需单独为伪元素设置animation-delay补偿，因为伪元素不在 Sass 字符计数范围内
字符数越多，Sass 编译出的关键帧规则越长，超过 200 字建议放弃纯 CSS 方案，改用 IntersectionObserver + requestAnimationFrame 控制 JS 动画节奏——Sass 不是万能胶，它只解决编译期可穷举的问题。
