浏览器里那个转得飞快的loading图标，其实是个骗局。它压根没在计算什么，只是用CSS的`animation`属性让一个半透明的圆环循环旋转。用户盯着它，心里默念“快了快了”，而背后的服务器可能还在处理一个需要三秒的查询。这种视觉上的“忙碌感”就是web动画的日常——它不负责真相，只负责感受。

前阵子我重构公司一个老后台系统，表格筛选按钮点击后，数据要等500毫秒才回来。500毫秒不长，但在交互里是一道明显的坎。我加了个简单的过渡：按钮按下时背景色从蓝变深，同时弹出一个细长的进度条从左侧滑入。效果出奇地好——用户反馈说“系统变快了”。其实查询时间没变，只是那500毫秒被动画填满了，等待变成了“正在进行”的暗示。这就是动画的心理学：它把死寂的空白变成有节奏的过程，大脑对节奏的容忍度远高于空白。

但动画不是越多越好。我见过一个数据可视化大屏，每个数字变化都要先放大1.2倍再缩回，柱状图每根柱子都有弹跳效果，页面切换还要来个3D翻转。结果整个屏幕像一群喝醉的蜜蜂在乱撞，用户根本找不到焦点。动画的本质是引导注意力，而不是分散注意力。好的动画像呼吸——你感觉不到它的存在，但节奏对了，整个页面就活了。糟糕的动画像哮喘，每一次换气都让你心惊肉跳。

技术层面，现在做web动画有两条路。一条是CSS3的`transition`和`keyframes`，适合处理位移、缩放、透明度这些简单属性，性能好，浏览器能直接调用GPU加速。另一条是JavaScript动画库，比如GSAP或者Framer Motion，适合做复杂的时间轴编排、物理模拟或者需要响应用户拖拽的交互。我的经验是：能用CSS解决的绝不上JS，因为JS跑在主线程上，一卡就全卡。但如果你要做那种“元素跟着鼠标轨迹飘散粒子”的效果，别犹豫，直接上GSAP，它内部处理了`requestAnimationFrame`的优化，比你手写靠谱得多。

有个细节很多人忽略——动画的缓动函数。默认的`ease`是慢-快-慢，看着中庸但不出错。但如果你想让一个卡片“啪”地弹进视野，用`cubic-bezier(0.68, -0.55, 0.265, 1.55)`这种带轻微回弹的曲线，瞬间就有生命力。我调过最极端的一个案例：一个下拉菜单展开时用了`steps(4)`做逐帧闪烁，配合音效，像老式霓虹灯管启动，整个页面突然有了性格。缓动不是数学题，是语气——你选择什么样的曲线，就是在用什么样的语气跟用户说话。

还要提性能。动画卡顿的元凶通常是强制同步布局——你改了元素的位置，又立刻去读它的偏移量，浏览器只能被迫提前计算布局。解决方法是把读操作和写操作分开，或者用`transform`代替`top/left`操作，因为`transform`不触发布局，只触发合成。我习惯在动画前先`element.getBoundingClientRect()`缓存好所有需要的数据，再一次性写入动画逻辑。还有，别忘了`will-change`属性，但别滥用——给太多元素加上它，浏览器会疯掉，内存占用直接翻倍。

最后说个反常识的：有些地方，动画越粗糙越好。比如一个加载失败的错误提示，如果弹出来还带平滑的缩放和阴影过渡，用户会觉得“这错误好像不太严重”。这时候用瞬间出现的红色边框加抖动效果，反而能传递正确的紧张感。动画不只是用来取悦眼睛的，它是信息的一部分——告诉用户现在发生了什么，接下来该注意什么。用对了，它是润滑剂；用错了，它是噪音。

(责任编辑：探索)