手写字效果四种做法：手写字体+写入动画、涂鸦笔顺序入场、关键帧模拟运笔

一、问题的本质：手写动效是时间轴控制权之争

先抛一个判断：所有手写字效果，无论实现多花哨，都可以用一句话概括——在时间 t，笔尖应该出现在哪里，以及已经"写"过的部分如何被呈现。前者是位置问题，后者是呈现问题。不同的技术路线，无非是把这两个问题的求解权交给了不同的角色。

如果求解权交给 CSS 的遮罩（mask/clip-path），那就是"手写字体+写入动画"；交给一条预先定义好的矢量路径，那就是"涂鸦笔顺序入场"；交给一组人工或算法生成的关键帧，那就是"关键帧模拟运笔"。本文评述：这三者的差别不在视觉结果，而在可控粒度——遮罩路线只能控制"横向进度"，路径路线能控制"笔顺方向"，关键帧路线能控制"提笔、顿笔、回锋"这类微观笔势。粒度越细，制作成本越高，这是绕不开的三角权衡。

1.1 一个被忽略的前置问题：你要的是"写字"还是"显字"

很多需求文档写的是"文字像手写一样出现"，但实际验收时，产品经理要的往往只是"从左到右擦出来"。这两者成本差一个数量级。笔者建议在动手前先明确三个问题：

• 是否需要笔顺正确？中文"口"字如果从左到右横擦，视觉上会非常怪异，因为真实书写是先竖后横折。
• 是否需要笔锋质感？即笔画粗细是否随运笔速度变化。这决定了要不要引入压力/速度模型。
• 是否需要可编辑？如果文案会动态变化，基于固定路径的方案就要重新生成路径。

这三个问题的答案，基本就锁定了技术路线。下面逐条展开。

二、做法一：手写字体 + 写入动画（遮罩驱动）

2.1 原理：用遮罩的宽度变化模拟"书写进度"

这是成本最低、兼容性最好的做法。核心思路是：先用一款手写风格字体把文字渲染出来，然后在其上方覆盖一个遮罩，让遮罩的可视区域随时间从左向右扩展。视觉上，文字就像被一支看不见的笔"写"了出来。

最朴素的实现是给容器加一个 overflow:hidden 的内层，用 width 动画驱动。但更现代、性能更好的方式是 clip-path: inset() 或 mask-image，因为它们不触发布局重排（reflow），只触发合成层重绘。

/* 遮罩驱动的手写动画 —— clip-path 方案 */
.handwrite {
  font-family: 'Ma Shan Zheng', 'Zhi Mang Xing', cursive;
  font-size: 48px;
  color: #4c1d95;
  /* 关键：用 inset 从右侧裁掉全部内容 */
  clip-path: inset(0 100% 0 0);
  animation: write 2.4s steps(40, end) forwards;
}

@keyframes write {
  from { clip-path: inset(0 100% 0 0); }
  to   { clip-path: inset(0 0 0 0); }
}

注意这里用了 steps(40, end) 而非线性缓动。这是一个容易被忽略的细节：线性缓动会让文字"平滑地长出来"，反而失去了手写的顿挫感；用 steps 制造离散跳变，视觉上更接近笔尖的逐段推进。步数的经验取值是字符数 × 8 到 12，太少会显得卡顿，太多则退化成线性。

2.2 手写字体从哪来

中文手写字体是这条路线的命脉。目前可免费商用的中文字体主要有：

需要提醒的是，中文字体文件体积普遍在 3MB 到 20MB 之间，直接引入会严重拖慢首屏。工程上的标准做法是字体子集化（subsetting）：只保留页面实际用到的字符。工具链上可以用 fonttools 的 pyftsubset，或前端侧的 subfont。一个只含 20 个汉字的子集，体积可以压到 10KB 以内。

本文评述：遮罩路线的最大优势是"文案可动态替换"——换一段文字，动画照样跑，因为它不依赖任何预生成的路径数据。但它的致命短板也在这里：遮罩只能横向推进，无法表达真实笔顺。用它写"一"很自然，写"回"就会露馅。所以这条路线适合短标题、单行、笔画简单的场景。

2.3 进阶：多行与逐字延迟

单行遮罩好办，多行就麻烦了——如果整体横向擦除，第二行会在第一行还没写完时就开始。正确做法是拆分为逐行、甚至逐字元素，用 animation-delay 串联：

/* 逐字延迟：用 CSS 变量把序号传进去 */
.char {
  --i: 0;
  clip-path: inset(0 100% 0 0);
  animation: write .6s steps(8, end) forwards;
  animation-delay: calc(var(--i) * 0.18s);
}

逐字延迟的间隔取值很讲究。太短（<0.1s）会糊成一片，太长（>0.3s）会让用户等得不耐烦。经验区间是 0.12s ~ 0.22s，且应随句子长度动态调整——长句用短间隔，短句用长间隔，保证整体时长控制在 2~3 秒。

三、做法二：涂鸦笔顺序入场（路径驱动）

3.1 原理：把每个笔画当成一条独立路径

如果说遮罩路线是"整体擦除"，那路径路线就是"逐笔绘制"。它的核心数据结构是：一个笔画数组，每个笔画是一条 SVG path，附带一个书写顺序和时长。动画时按顺序依次触发每条 path 的描边动画。

这里的关键技术是 SVG 的 stroke-dasharray 与 stroke-dashoffset 组合。原理是：把路径的虚线长度设为路径总长，偏移量设为总长，此时路径完全不可见；然后把偏移量动画到 0，路径就"长"出来了。

/* 单笔画描边动画 */
.stroke {
  fill: none;
  stroke: #7c3aed;
  stroke-width: 6;
  stroke-linecap: round;
  stroke-linejoin: round;
  /* 用 JS 读取 getTotalLength() 后写入 */
  stroke-dasharray: var(--len);
  stroke-dashoffset: var(--len);
  animation: draw 0.5s ease-out forwards;
}
@keyframes draw {
  to { stroke-dashoffset: 0; }
}

路径总长必须用 JS 读取，因为 CSS 拿不到 getTotalLength()：

document.querySelectorAll('.stroke').forEach((el, i) => {
  const len = el.getTotalLength();
  el.style.setProperty('--len', len);
  el.style.animationDelay = `${i * 0.4}s`;
});

3.2 路径数据从哪来

这是路径路线最费工的部分。三条获取途径：

1. 字体转路径。用 Illustrator 或 Inkscape 把文字转成轮廓，再手工拆分笔画。适合字数固定的 Logo 或标题。
2. 在线描摹工具。如 SVG Path Visualizer、Method Draw 等，可以手绘后导出 path。
3. 程序化生成。用 opentype.js 读取字体文件，提取字形轮廓，再按轮廓的拓扑结构切分笔画。这条路自动化程度最高，但笔画切分算法本身是个研究课题。

第三条路值得多说一句。opentype.js 能把 TTF/OTF 解析成字形路径，但字形轮廓是"填充区域"而非"书写轨迹"，直接描边会得到空心字。要得到真正的单线笔画，需要做骨架化（skeletonization）处理。学术界对此有大量研究，经典的 Zhang-Suen 细化算法（Zhang & Suen, 1984）至今仍是很多实现的基础。本文评述：骨架化能把轮廓压成单像素中轴线，但会丢失笔画宽度信息，若要做笔锋效果，还需额外估计每个骨架点的局部宽度。

3.3 时间分配：按路径长度而非笔画数

一个常见错误是给每个笔画分配相同的时间。结果就是长横"唰"地一下过去，短点却慢吞吞。正确做法是按路径长度比例分配时长：

const totalLen = strokes.reduce((s, el) => s + el.getTotalLength(), 0);
const TOTAL_DURATION = 2400; // ms
let acc = 0;
strokes.forEach(el => {
  const len = el.getTotalLength();
  const dur = (len / totalLen) * TOTAL_DURATION;
  el.style.animationDuration = dur + 'ms';
  el.style.animationDelay = acc + 'ms';
  acc += dur;
});

这样处理之后，整体节奏会自然很多。但要注意：真实书写中，长笔画往往运笔更快，所以可以引入一个速度补偿系数，让长笔画的单位长度耗时略低于短笔画。经验上，把时长对长度的幂次设为 0.8 左右（即 dur ∝ len^0.8）比严格线性更接近真人书写。

四、做法三：关键帧模拟运笔（插值驱动）

4.1 原理：把"笔"抽象成一个可插值的对象

前两种做法关注的是"字"，这一种关注的是"笔"。核心思路是：定义一个笔尖对象，它有一系列随时间变化的属性——位置 (x, y)、角度、压力、速度。然后按关键帧逐帧插值，实时绘制笔迹。

这种做法的理论根基可以追溯到 Bézier 曲线插值与 Catmull-Rom 样条。当关键帧点稀疏时，用 Catmull-Rom 样条可以生成平滑且过点的曲线，比三次 Bézier 更直观，因为 Bézier 的控制点不落在曲线上，调参反直觉。

// Catmull-Rom 插值：给定 P0 P1 P2 P3，求 P1 到 P2 之间 t 处的点
function catmullRom(p0, p1, p2, p3, t) {
  const t2 = t * t, t3 = t2 * t;
  return {
    x: 0.5 * ((2*p1.x) + (-p0.x + p2.x)*t
        + (2*p0.x - 5*p1.x + 4*p2.x - p3.x)*t2
        + (-p0.x + 3*p1.x - 3*p2.x + p3.x)*t3),
    y: 0.5 * ((2*p1.y) + (-p0.y + p2.y)*t
        + (2*p0.y - 5*p1.y + 4*p2.y - p3.y)*t2
        + (-p0.y + 3*p1.y - 3*p2.y + p3.y)*t3)
  };
}

4.2 笔锋：让粗细随速度变化

关键帧路线真正拉开差距的地方，是它能模拟笔锋。真实毛笔书写中，运笔越快笔画越细，顿笔时笔画变粗。这个规律可以用一个简单的反比模型近似：

width = clamp(baseWidth / (1 + k * speed), minW, maxW)

其中 speed 是当前点相对前一点的距离除以时间间隔，k 是灵敏度系数。这个模型并非严格物理正确，但视觉上足够可信。本文评述：学术界对毛笔笔迹的建模更复杂，会引入压力、墨量、纸张吸墨率等变量（可参考 Xu 等人在 NPAR 会议上的系列工作），但对前端动效而言，视觉可信度远比物理精确度重要，过度建模反而增加性能负担。

4.3 用 Web Animations API 驱动

关键帧路线不一定非要用 requestAnimationFrame 手写循环。Web Animations API（WAAPI）支持对任意数值属性做插值，配合 onupdate 回调，可以把插值结果同步到 Canvas 绘制：

const progress = { t: 0 };
const anim = progress.animate(
  [{ t: 0 }, { t: 1 }],
  { duration: 2000, easing: 'ease-in-out', fill: 'forwards' }
);
anim.onupdate = () => {
  // 用 progress.t 去采样样条，得到笔尖位置
  const pt = sampleSpline(spline, progress.t);
  drawStroke(ctx, pt);
};

WAAPI 的好处是动画跑在合成线程上，主线程卡顿不会影响时间推进的准确性。但它对 Canvas 绘制本身无能为力——绘制仍在主线程。所以如果笔迹复杂，还是要把绘制量控制住。

五、做法四：SVG 描边与 Canvas 粒子的补充路径

5.1 SVG 描边：路径路线的轻量变体

严格说，SVG 描边不算独立做法，而是路径路线的实现载体。但它有一个独特优势：矢量、可缩放、可被 CSS 直接控制。对于需要响应式适配的场景，SVG 比 Canvas 省心得多。配合 vector-effect="non-scaling-stroke"，还能保证描边宽度不随缩放变化。

5.2 Canvas 粒子：追求"墨迹飞溅"的视觉冲击

当需求从"写字"升级到"墨迹飞溅"时，Canvas 粒子系统就登场了。基本思路是：沿笔迹路径撒粒子，每个粒子有独立的速度、生命周期和透明度衰减。渲染时用 globalCompositeOperation = 'lighter' 叠加发光效果。

这类效果的性能瓶颈在粒子数量。经验值是：桌面端单帧粒子数控制在 2000 以内，移动端 500 以内，否则帧率会掉到 30fps 以下。优化手段包括：用离屏 Canvas 缓存静态笔迹、用 typed array 存储粒子属性、按需降采样。

本文评述：粒子方案视觉冲击力最强，但也是最"重"的。它适合开场动画、H5 营销页这类一次性、短时长的场景，不适合常驻 UI。笔者见过不少项目为了"炫技"把粒子效果放进登录页，结果首屏加载时间翻倍，得不偿失。

六、四种做法的横向对比与选型决策

把四种做法放在同一张表里对比，选型逻辑就清晰了：

选型决策可以简化成三个问题：文案会不会变？要笔顺吗？要笔锋吗？三个都否，用遮罩；要笔顺不要笔锋，用路径；全都要，上关键帧。粒子方案只在"视觉冲击优先于一切"时才考虑。

七、中文场景的特殊约束：笔画数、字库与时长

7.1 笔画数分布决定了动画时长的天花板

中文和英文在手写动效上的最大差别，是笔画数的方差极大。英文 26 个字母，每个字母 1~4 笔，方差很小；而汉字从 1 笔（"一"）到 30 多笔（"齉"）都有。根据《现代汉语常用字表》的统计，3500 个常用字的平均笔画数约为 9.5 画，中位数在 8~9 画之间（数据来源：教育部《现代汉语常用字表》及相关字频统计研究）。

这个分布对动效设计有直接影响：如果按"每笔 0.3 秒"设计，一个 9 画的字要 2.7 秒，一句话 10 个字就是 27 秒，用户早就跑了。所以中文手写动效必须做时长压缩——要么按整句分配固定总时长，要么对笔画做合并（把相邻短笔画视作一笔）。

7.2 字库体积与加载策略

前文提到子集化，这里补充一个更激进的方案：按需加载。用 unicode-range 把字体切片，浏览器只下载页面实际用到的分片。Google Fonts 的中文方案就是这么做的，把几万个汉字切成上百个分片，每个分片几十 KB。

@font-face {
  font-family: 'MyHandwrite';
  src: url('handwrite-0.woff2') format('woff2');
  unicode-range: U+4E00-4EFF; /* 只覆盖部分汉字区间 */
  font-display: swap;
}

font-display: swap 这个属性值得强调。它让文字先用系统字体渲染，等手写字体加载完再替换。如果不加，用户会看到一段空白，体验很差。但 swap 也有副作用——字体替换瞬间会有明显的"跳变"（FOUT）。对动效场景，这个跳变可能正好发生在动画开始时，非常突兀。折中方案是用 font-display: optional，或者干脆用 JS 监听 document.fonts.ready，等字体就绪再启动动画。

八、前沿进展：可变字体、AI 笔迹合成与可访问性

8.1 可变字体：一个字体文件搞定粗细变化

可变字体（Variable Fonts）是 OpenType 1.8 规范引入的特性，允许在单个字体文件内定义多个设计轴（如字重 wght、字宽 wdth、倾斜 slnt）。对手写动效而言，如果字体本身带有一个"书写进度"轴，理论上可以直接用 font-variation-settings 驱动动画，无需遮罩或路径。

目前公开的带"书写进度"轴的中文字体极少，但西文领域已有实验性项目。本文评述：这个方向潜力巨大，因为它把"动效"下沉到了字体层面，前端只需改一个数值。但中文字形复杂，为每个字定义书写轴的数据量惊人，短期内难以普及。

8.2 AI 笔迹合成：从静态字到书写轨迹

近三年，用深度学习从静态字形反推书写轨迹的研究明显增多。代表性思路包括：用序列模型（LSTM/Transformer）把字形轮廓编码后解码成笔尖轨迹序列，或用扩散模型生成多样化的书写风格。相关数据集如 CASIA-HWDB（中科院自动化所手写汉字库）和 CVL Database 常被用作训练与评测基准。

需要说明的是，这些研究的输出是"轨迹数据"，要落地到前端还需要一步转换——把轨迹转成 SVG path 或 Canvas 绘制指令。目前已有开源工具在做这件事，但成熟度参差。笔者认为，AI 笔迹合成短期内不会取代手工路径，但会大幅降低"批量生成手写素材"的成本，这对需要大量手写内容的场景（如在线教育、电子贺卡）意义重大。

8.3 可访问性：动效不能成为障碍

WCAG 2.2 的 2.3.3 条款（Animation from Interactions）明确要求：用户应能关闭非必要的动效。手写动画属于典型的"装饰性动效"，必须尊重系统的 prefers-reduced-motion 设置：

@media (prefers-reduced-motion: reduce) {
  .handwrite {
    animation: none;
    clip-path: none;   /* 直接显示完整文字 */
  }
}

这一点在中文项目里经常被忽略。笔者见过不少页面，用户开了"减弱动态效果"后，文字仍然一个字一个字地蹦出来，体验很糟。加上这段媒体查询，成本几乎为零，收益却很实在。

九、工程落地清单与常见坑

9.1 落地清单

1. 先确认"写字"还是"显字"，据此选路线。
2. 中文字体务必子集化，目标体积 < 100KB。
3. 用 document.fonts.ready 等字体就绪再启动动画。
4. 路径方案用 getTotalLength() 按长度分配时长，幂次取 0.8。
5. 遮罩方案用 clip-path 或 mask，避免 width 动画触发重排。
6. 整体时长控制在 2~3 秒，逐字延迟 0.12~0.22 秒。
7. 加 prefers-reduced-motion 降级。
8. 用 will-change 提示合成层，但别滥用。

9.2 常见坑

• 坑一：用 width 做遮罩动画，导致每帧重排，长文本卡顿明显。
• 坑二：忘记 stroke-linecap: round，笔画端点出现生硬的方角。
• 坑三：路径总长在响应式缩放下变化，但 stroke-dasharray 是按固定值算的，导致动画错位。解决：用 ResizeObserver 监听尺寸变化后重算。
• 坑四：字体加载失败时动画照跑，结果用系统字体渲染，遮罩宽度和字形对不上，出现"文字被切一半"的诡异效果。

十、结语

回到开头那条主线：手写字效果的本质是时间轴控制权的分配。遮罩路线把控制权交给 CSS，路径路线交给预定义矢量，关键帧路线交给插值算法。没有哪条路线绝对更优，只有哪条更匹配你的约束——文案是否动态、笔顺是否重要、制作预算多少、性能要求多高。

笔者倾向于一个务实的判断：80% 的需求用遮罩路线就够了，剩下 20% 里的大部分用 SVG 描边能解决，真正需要关键帧或粒子的场景少之又少。与其追求技术上的"高级感"，不如把加载性能、降级策略、可访问性这些基础工作做扎实。毕竟，一个加载 3 秒才出现的手写动画，再精致也留不住用户。

主要参考文献