纯CSS打字机效果通过width动画+overflow:hidden截断+steps()分步实现，需等宽字体、禁换行、精确匹配字符数，动态适配依赖JS或预处理器，且存在跨浏览器渲染差异。
为什么 width + steps() 能模拟打字机效果
纯 CSS 实现打字机效果，本质是让文字「逐字显现」。但 CSS 没有“字符级渲染控制”，所以得绕道：用 width 从 0 动态展开容器，配合 overflow: hidden 截断内容，再用 steps() 让展开过程不平滑——每一步卡在整数宽度上，视觉上就接近“一个字、停顿、下一个字”。关键在于：steps(6, end) 中的 6 必须和文字总字符数严格对应（或略多），否则会漏字或卡住。
-
steps()的第二个参数用end（不是start），否则首字符会延迟一帧才出现 - 字体必须是等宽（
font-family: monospace）或已知单字符宽度，否则width扩展无法对齐字数 - 中文/Emoji 等非等宽字符会导致错位，此时应改用
ch单位（1ch≈ 数字 0 的宽度），而非px或em
overflow: hidden 和 white-space: nowrap 缺一不可
只设 width 动画却没限制溢出，文字会直接撑开容器、根本看不到“打字”过程。而如果允许换行（默认 white-space: normal），动画过程中文字可能折行，导致宽度计算失效、steps() 步骤错乱。
- 必须同时声明：
overflow: hidden+white-space: nowrap - 父容器不能有
padding或border干扰宽度基准，否则动画起始点偏移 - 若文本含空格或连字符，需额外加
word-break: keep-all防止浏览器主动断词
如何适配不同长度文本而不重写动画
硬编码 steps(12) 只适用于固定 12 字文本。实际项目中，文本长度常变，手动改 steps() 值既脆弱又不可维护。可行解是用 CSS 自定义属性动态传入字数：
span {
--char-count: 15;
animation: type var(--char-count) * 0.25s steps(var(--char-count), end);
}
@keyframes type {
from { width: 0; }
to { width: calc(var(--char-count) * 1ch); }
}但注意：calc() 里不能直接用 var(--char-count) 做乘法（CSS 不支持变量参与运算），所以上面写法仅示意逻辑。真实做法是 JS 注入样式，或用预处理器编译时计算。
立即学习“前端免费学习笔记（深入）”；
- 服务端渲染或构建时已知文本长度 → 用 PostCSS 或 SASS 动态生成
steps(N)和width终值 - 客户端动态文本 → 用 JS 读取
textContent.length，设置style.setProperty('--char-count', len)，再触发重绘 - 避免用
ch单位计算中文宽度（1ch对中文不准确），此时应测出该字体下中文平均宽度（如18px），改用px+ JS 测量
动画卡顿、首帧闪动或末尾跳变的常见原因
看似简单的 CSS 动画，上线后常出现第一帧全显、中间卡两帧、最后一字突然弹出等问题。根因往往不在动画本身，而在渲染链路干扰。
- 未加
will-change: width，尤其在低性能设备上，width动画易掉帧 - 父元素用了
transform（如translateZ(0)）创建新层叠上下文，导致子元素overflow: hidden失效 - 动画结束时
width设为100%或fit-content，而非精确值，造成末尾回弹 - 字体加载完成前就执行动画 → 加
@font-face的font-display: block，或监听document.fonts.load()后再触发动画
最麻烦的是：不同浏览器对 steps() 的实现细节有差异，Safari 对小数值步长更敏感，Chrome 在 subpixel 渲染下偶有 1px 抖动。真要稳定，就得接受——它只是近似模拟，别指望像素级一致。
