loading动画必须写全animation: spin 1s linear infinite，缺infinite则只播一次，缺linear则默认ease导致卡顿；spin名须与@keyframes一致且大小写敏感；时长宜为0.8s～1.2s；@keyframes中应写0%和100%并用359deg避360deg优化陷阱；仅保留transform/opacity以走合成层；移动端必加will-change: transform且需JS控制生命周期；推荐border-top配色方案替代SVG，尺寸用rem/em。
animation: spin 1s linear infinite 必须写全
漏掉 infinite，动画播完一次就停，用户根本收不到“还在加载”的视觉信号；漏掉 linear，浏览器默认用 ease，导致旋转开头慢、结尾快，转圈像卡顿或抽搐。这两个值不是可选修饰，是 loading 动画成立的前提。
常见错误写法：animation: spin 1s; 或 animation: spin 1s infinite; —— 后者看似循环，但节奏不稳，尤其在低端安卓机上更明显。
-
spin名称要和@keyframes spin完全一致，大小写敏感 - 时长建议落在
0.8s～1.2s区间：太短（如0.3s）易丢帧；太长（如2s）让用户误判为卡死 - 不要写
animation-iteration-count: infinite单独声明——它只是animation简写的一部分，拆开反而容易漏配 timing-function
@keyframes 里别用 rotate(360deg)
直接写 to { transform: rotate(360deg); } 在某些 Chromium 版本（尤其是 Android WebView）中会被渲染引擎优化掉整圈变换，造成首帧跳变、偶发停顿甚至动画“消失”。这不是 bug，是浏览器对 360° 的特殊处理逻辑。
稳妥写法是避开整数倍角度：
立即学习“前端免费学习笔记（深入）”；
@keyframes spin {
0% { transform: rotate(0deg); }
100% { transform: rotate(359deg); }
}这个小偏移不会影响视觉观感，但能绕过底层优化陷阱，保证每一帧都真实触发。
- 不用
from/to，统一用0%/100%，兼容性更稳 - 避免在 keyframes 里写其他会触发布局的属性（比如
width、height），只保留transform和opacity，才能走合成层（compositor），不卡主线程
移动端必须加 will-change: transform
哪怕只是个纯 CSS 旋转 loader，在 iOS Safari 或部分安卓 Chrome 上，不加 will-change: transform 就可能掉帧。这不是玄学——浏览器需要提前知道这个元素将频繁做 transform 变换，才会把它提升到独立图层并启用 GPU 加速。
加的位置很简单：
.loader {
/* 其他样式 */
animation: spin 1s linear infinite;
will-change: transform;
}- 只加在动画元素本身，不要加在父容器上
- 不要滥用：仅限真正持续动画的元素，否则内存开销会上升
- 如果 loader 是通过 JS 控制显隐的，建议在显示前一刻再加该声明（例如用
element.style.willChange = 'transform'），避免长期占用图层资源
border-top 配色方案比纯 SVG 更轻量且可控
比起引入 SVG 或 canvas，用 border + border-radius: 50% 做旋转圆环，体积小、颜色尺寸全由 CSS 控制，适配深色模式也只需改变量。
典型结构：
.loader {
width: 40px;
height: 40px;
border: 4px solid #eee;
border-top-color: #007bff;
border-radius: 50%;
animation: spin 1s linear infinite;
}- 四边框设为浅灰，只让顶部着色，旋转时自然形成“流动色块”效果
- 尺寸用
rem或em替代固定px，能随根字号缩放，更好适配不同屏幕密度 - 避免用
background-image或伪元素模拟边框——多一层绘制，增加重排风险
实际项目中最容易被忽略的，是把 will-change 当成“加了就稳”的万能药，却没配合 JS 控制它的生命周期。它该出现时出现，该清除时清除，否则在长列表或单页应用里，图层堆积会导致内存缓慢上涨。
