anime.js 使用体验：为什么我又开始认真看前端动画库

前端动画这件事，我以前一直是又喜欢、又有点克制。
喜欢是因为它确实能让页面更有生命力，克制是因为大多数时候，动画一旦写得太重，就很容易从“增强体验”变成“抢走注意力”。

所以这次重新看 anime.js，我最关心的并不是“它能不能做出很炫的效果”，而是两件更实际的事：

• 它现在的 API 还顺不顺手
• 它适不适合放进一个真实在维护的 Nuxt 博客里

anime.js 官网

官方站点与演示入口，包含主页、文档、easings 编辑器与学习资源。

anime.js Documentation

v4 官方文档，重点包括安装、模块导入、Scope、WAAPI、Layout、Text、SVG 和实用工具。

我为什么会重新注意到 anime.js

这次并不是因为我要专门做一个动画项目，而是因为我想给博客右侧的信息卡片加一点更自然的动态反馈。
如果只是简单地补几个 CSS transition，很多时候只能做到“有变化”，但做不到“有节奏”。而一旦想把多个元素串起来，像延迟、交错、回弹、批量控制这些需求就会马上出现。

我在当前项目里最先落地的是这一句：

import { animate, stagger } from 'animejs'

它被我放在了访客信息卡片里，用来控制地图、节点和连线出现时的时序。
从这个切入点往下走，我才开始真正把 v4 的文档重新看了一遍。

anime.js 现在最吸引我的几个点

1. 模块优先这件事，真的很对胃口

我现在更喜欢的库，基本都有一个共同点：
不是把所有东西揉成一个巨大的默认导出，而是把功能拆得足够清楚，按需拿来用。

anime.js v4 这一点做得很明确。官方文档里直接把它描述成 modules-first API，而且强调了 tree shaking 支持。你既可以这样导入：

import { animate, stagger } from 'animejs'

也可以按子路径拆开：

import { animate } from 'animejs/animation'
import { stagger } from 'animejs/utils'

这类设计的好处不是“语法更酷”，而是它让动画库更像一个可以组合的工具箱，而不是一个必须整体接受的黑盒。

2. Scope 让我觉得它更像现代前端项目里的工具

如果只是做一个孤立的 demo，很多动画库都很好用。
但一旦回到真实项目，问题马上会变成：

• 组件卸载以后怎么清理
• 响应式布局变化以后怎么重建
• prefers-reduced-motion 怎么处理
• 不同 root 下的元素怎么隔离

anime.js v4 的 createScope() 就是在处理这一层问题。官方文档里对 Scope 的描述很直白：它可以响应 media query、使用自定义 root、共享默认参数，还能成批回收实例。

这让我觉得它不只是一个“补间动画函数”，而是一套有工程意识的动画组织方式。

如果你本来就在做组件化项目，这种感觉会很明显：

• 动画不再只是“某个元素动一下”
• 而是“这个组件的动画生命周期怎么和组件本身绑在一起”

3. 它对 WAAPI 的态度很成熟

我挺喜欢 anime.js 官方在 WAAPI 这块的方向。
它不是说“别用原生 Web Animations API，来用我的”，而是直接提供了 waapi.animate() 这套增强层。

官方文档里提到，它在 WAAPI 之上补了很多使用层面的体验改进，比如：

• 更合理的默认值
• 多目标动画
• 默认单位
• 函数式值
• 单独 transform 属性
• spring 和自定义 easing

对我来说，这种思路比单纯造一套完全平行的新轮子更有说服力。
因为浏览器原生能力迟早会越来越强，而一个成熟的动画库，真正重要的是它怎么把这些能力组织得更顺手。

4. 它不像只会做“元素飞来飞去”

我重新看文档时还有个明显感受：
anime.js 现在已经不是我早几年印象里那个“写几个 translate / opacity 很方便”的库了。

它现在的能力面明显更宽，官方文档里能直接看到这些分区：

• timeline
• utils
• svg
• text
• waapi
• layout
• scope

这意味着它已经不只是拿来做局部点缀。
如果你愿意，它其实可以参与页面进入、批量排序、文字拆分、滚动驱动、布局切换这些更完整的交互层。

在这个博客里，我现在是怎么开始用它的

我没有一上来就拿它重做全站动画，而是只放在一个足够局部、又能看出节奏感的地方：右侧访客信息卡片。

当前这部分主要用了：

• animate()
• stagger()

做的事情也比较克制：

• 地图淡入
• 地区高亮
• 弧线路径出现
• 粒子沿路径移动
• 统计信息分批出现

我喜欢这种起步方式。
因为它不会让整个站一下子“动画味”太重，但足够让我判断一件事：这套库在真实项目里是不是顺手。

到目前为止，我的答案是：顺手，而且继续往下加也有空间。

我觉得 anime.js 适合什么场景

如果你只是做一两个简单 hover，CSS 当然还是最轻的方案。
但如果你开始需要：

• 多元素联动
• 批量交错
• 可回收的组件动画
• 与滚动、布局、文字拆分结合

那 anime.js 就会很快显出价值。

我目前的判断

如果只用一句话总结我这次的感受，我会这么说：

anime.js 现在最可贵的地方，不是它“还能做动画”，而是它已经越来越像一套适合现代前端项目的动画工具系统。

它保留了早年那个上手快、写起来顺的优点，但 v4 又明显往工程化、多模块和组件环境靠了一步。
这一步对我来说，比单纯多出几个炫技效果更重要。

至少在这个博客里，我已经愿意继续把它用下去了。
下一步如果我继续往下做，大概率会去试：

• createTimeline()
• createScope()
• 更自然的页面进入动画
• 更轻一点的滚动触发效果

如果后面真的把它用深了，我还会再写第二篇，聊聊 anime.js 在真实 Nuxt 页面里的取舍，而不是只停留在“它看起来很强”这一步。