1. 从一行标题拆出来的真实需求
“可视化2D动画—cavas旋转的圈”，这个标题第一次看到的时候，我脑子里冒出来的画面特别具体：一个用 Canvas 画出来的圆环，可能是一圈点、一圈线段、一圈渐变色块，然后它在那儿匀速转，或者带点缓动地转。听起来简单得不行，但真正动手写过的人都知道，这里面能踩的坑一点都不少。
先把话说清楚：Canvas 是 HTML5 提供的一个绘图接口，它本身不是动画引擎，只是一块画布加一堆绘图 API。你要让上面的东西动起来，靠的是每秒钟清空画布、重新画一遍这个最朴素的逻辑。所谓“旋转的圈”，本质上就是每一帧里，把圆上每个元素的角度加上一个增量，再根据新的角度算出坐标，重新绘制。这个增量怎么定、帧率怎么控、性能怎么保，才是这个项目真正要解决的问题。
这个内容适合谁看？如果你刚学完 Canvas 基础 API，能画线画圆但不知道怎么让画面动起来，那这篇正好。如果你已经会写动画但总觉得自己的圆转起来有点卡、有点抖、或者元素一多就掉帧，那这篇里关于帧率控制和分层渲染的部分应该对你有用。如果你是想做一个加载动画、数据可视化里的环形进度、或者某个交互组件里的旋转指示器，那这套思路可以直接拿去改。
我打算把这个项目从头到尾拆一遍：为什么用 Canvas 而不是别的方案、旋转的数学原理到底怎么回事、代码怎么写才能又稳又顺、以及我在实际写这类动画时踩过的那些坑。不堆概念，直接上能跑的东西。
2. 方案选型：为什么是 Canvas，而不是 CSS 或 SVG
2.1 三种主流方案的真实差异
要做“旋转的圈”，摆在面前的路其实有三条：纯 CSS 动画、SVG 动画、Canvas 绘制。很多人第一反应是用 CSS，因为写起来最短——一个@keyframes加transform: rotate()就完事了。但这里有个关键区别：CSS 旋转的是整个元素，而 Canvas 旋转的是元素内部的每一个绘制单元。
这两者的差别在简单场景下看不出来，一旦你的圈不是“一个实心圆环”，而是“一圈均匀分布的小圆点，每个点还要有自己的颜色和大小变化”，CSS 就抓瞎了。你没法用一条 CSS 规则让 36 个独立的小点各自按不同相位旋转。SVG 倒是可以，每个点是一个独立元素，但元素一多，DOM 节点数量上去，浏览器要维护的样式计算和重排成本就压不住了。
Canvas 的优势在这里就体现出来了：整块画布就是一个 DOM 元素，里面画多少东西浏览器都不关心，它只知道“这块区域被重绘了”。所以当你的圈要承载几十上百个绘制单元时，Canvas 的渲染开销基本是恒定的，而 SVG 和 DOM 方案会随元素数量线性增长。
我做过一个粗略的对比测试，同样画 200 个小圆点组成的旋转圈，三种方案在普通笔记本上的表现大致是这样：
| 方案 | 200 元素帧率 | 内存占用 | 代码复杂度 | 适合场景 |
|---|---|---|---|---|
| CSS 动画 | 不适用 | 低 | 极低 | 单个整体旋转 |
| SVG | 约 45fps | 中高 | 中 | 元素少、需交互 |
| Canvas | 稳定 60fps | 低 | 中 | 元素多、纯视觉 |
注意：这个数据不是绝对的，跟设备性能、浏览器版本都有关系，但趋势是稳定的——元素越多，Canvas 优势越明显。
2.2 什么情况下不该用 Canvas
我也得说句公道话，Canvas 不是万能的。如果你的圈就是单纯一个圆环在转，没有任何内部元素的变化，那用 CSS 是最省事的，性能也够。Canvas 的代价在于：你得自己管理动画循环、自己处理高分屏适配、自己算坐标。这些在 CSS 方案里浏览器帮你做了。
还有一个容易被忽略的点：Canvas 绘制的内容对无障碍访问不友好。屏幕阅读器读不到画布里的东西。如果你的旋转圈承载了重要信息（比如环形进度条显示百分比），那要么在画布外面用文字补一份，要么考虑 SVG。纯装饰性的旋转动画，这个问题就不存在。
所以我的判断标准很简单：圈里有独立变化的多个元素，用 Canvas；圈本身整体转、没有内部变化，用 CSS；需要每个元素单独交互（比如点击某个点），用 SVG。这个项目标题里说的是“旋转的圈”，我默认按最典型的场景来做——一圈由多个绘制单元组成的环，整体旋转，每个单元可以有自己的样式。
3. 旋转的数学：角度、弧度与坐标换算
3.1 从角度到坐标的那一步
很多人卡在第一步：我知道要转，但怎么让一个点绕着圆心转？这里涉及一个最基础但最容易搞混的换算。
Canvas 的坐标系里，圆心在(cx, cy)，半径是r。圆上任意一个点的位置由角度决定。但 JavaScript 的Math.sin和Math.cos接收的是弧度，不是角度。所以每次算坐标之前，得先把角度转成弧度：
弧度 = 角度 × π / 180一个完整的圆是 360 度，对应 2π 弧度。这个换算我建议直接写成一个工具函数，因为后面每一帧都要用：
const degToRad = (deg) => deg * Math.PI / 180;然后圆上某一点的坐标就是：
const x = cx + r * Math.cos(degToRad(angle)); const y = cy + r * Math.sin(degToRad(angle));这里有个细节值得说：Canvas 的 y 轴是向下的，所以Math.sin算出来的正值对应的是圆心下方的点。如果你想让角度从正上方开始算（12 点钟方向），需要在角度上减 90 度，或者用-Math.PI / 2作为起始偏移。这个偏移量在画环形进度条的时候特别重要，不然你的起点永远在右边（3 点钟方向）。
3.2 每帧的角度增量怎么定
旋转的速度由每帧增加多少角度决定。假设你要让圈每秒转一圈，也就是 360 度/秒。如果动画跑在 60fps，那每帧增加 6 度。但这里有个陷阱：不能假设帧率永远是 60fps。
如果你写死angle += 6，在性能好的设备上圈转得快，在性能差的设备上圈转得慢，因为帧率不一样。正确的做法是用时间差来算增量：
const speed = 360; // 度/秒 let lastTime = 0; function animate(currentTime) { const deltaTime = (currentTime - lastTime) / 1000; // 转成秒 lastTime = currentTime; angle += speed * deltaTime; // ... 绘制 requestAnimationFrame(animate); }这样不管帧率是 30 还是 120，圈转一圈的时间都是 1 秒。这个思路叫基于时间的动画，是所有流畅动画的基础。我见过太多人写死增量，然后在不同设备上效果不一致，排查半天才发现是帧率问题。
提示：
requestAnimationFrame的回调参数currentTime是高精度时间戳，单位是毫秒。第一次调用时lastTime是 0，算出来的deltaTime会很大，导致第一帧跳一下。解决办法是在第一次调用时把lastTime初始化成currentTime，跳过第一帧的增量计算。
3.3 缓动让旋转不那么机械
匀速旋转看久了会有点呆。如果你想让圈有“加速—匀速—减速”的感觉，可以引入缓动函数。最简单的做法是用正弦波调制速度：
const easedSpeed = speed * (0.5 + 0.5 * Math.sin(currentTime / 1000));这样速度会在 0 到 speed 之间周期性变化，圈转起来就有呼吸感。更复杂的缓动可以用三次贝塞尔曲线，但对于旋转圈来说，正弦调制已经够用了。我试过在加载动画里用这个技巧，比匀速转看起来“活”很多。
4. 核心实现：从零搭一个旋转的圈
4.1 画布初始化与高分屏适配
第一步是把画布准备好。这里有个几乎所有人都会踩的坑：高分屏下画布会模糊。原因是 Canvas 的绘制尺寸和显示尺寸是两回事。在 Retina 屏上，一个 300×300 的 CSS 像素区域实际有 600×600 的物理像素，如果你只按 300×300 来画，浏览器会拉伸，结果就是糊的。
解决办法是让画布的width和height属性等于显示尺寸乘以设备像素比，然后用 CSS 把它压回显示尺寸：
const canvas = document.getElementById('ring'); const ctx = canvas.getContext('2d'); const dpr = window.devicePixelRatio || 1; const displaySize = 300; canvas.width = displaySize * dpr; canvas.height = displaySize * dpr; canvas.style.width = displaySize + 'px'; canvas.style.height = displaySize + 'px'; ctx.scale(dpr, dpr);最后那句ctx.scale(dpr, dpr)是关键，它让后续所有绘制操作都按逻辑像素来算，不用每次手动乘 dpr。这个套路我建议直接背下来，任何 Canvas 项目开头都这么写。
4.2 绘制一圈元素的两种思路
画“一圈东西”有两种常见做法，各有适用场景。
第一种是画一个圆环路径，用虚线模拟分段。设置lineDash为[段长, 间隔]，然后画一个整圆，看起来就是一圈断开的弧。这种做法的好处是代码极短，性能极好，适合做刻度盘、虚线环。缺点是每段的样式没法单独控制，颜色、粗细都是统一的。
第二种是循环计算每个元素的位置，逐个绘制。比如要画 36 个小圆点，就循环 36 次，每次算出角度和坐标，画一个小圆。这种做法的好处是每个点可以有自己的颜色、大小、透明度，适合做有层次感的装饰环。缺点是元素多了性能会下降，但一般几十个点完全没问题。
我两种都写过，选择标准是：样式统一用虚线，样式各异用循环。这个项目标题说的是“旋转的圈”，我默认按第二种来做，因为更有发挥空间。
4.3 完整可运行的代码骨架
下面这份代码是我在实际项目中反复用过的骨架，直接改改就能用：
const canvas = document.getElementById('ring'); const ctx = canvas.getContext('2d'); const dpr = window.devicePixelRatio || 1; const size = 300; const cx = size / 2; const cy = size / 2; const radius = 110; const dotCount = 36; const dotRadius = 4; canvas.width = size * dpr; canvas.height = size * dpr; canvas.style.width = size + 'px'; canvas.style.height = size + 'px'; ctx.scale(dpr, dpr); let angle = 0; let lastTime = 0; const speed = 60; // 度/秒 function degToRad(deg) { return deg * Math.PI / 180; } function draw(currentTime) { if (!lastTime) lastTime = currentTime; const deltaTime = (currentTime - lastTime) / 1000; lastTime = currentTime; angle += speed * deltaTime; ctx.clearRect(0, 0, size, size); for (let i = 0; i < dotCount; i++) { const dotAngle = angle + (360 / dotCount) * i; const rad = degToRad(dotAngle); const x = cx + radius * Math.cos(rad); const y = cy + radius * Math.sin(rad); // 根据角度算透明度，做出渐变尾巴的效果 const alpha = 0.2 + 0.8 * ((i / dotCount)); ctx.beginPath(); ctx.arc(x, y, dotRadius, 0, Math.PI * 2); ctx.fillStyle = `rgba(80, 160, 255, ${alpha})`; ctx.fill(); } requestAnimationFrame(draw); } requestAnimationFrame(draw);这段代码跑起来就是一个由 36 个蓝色小点组成的圈，整体匀速旋转，每个点的透明度从 0.2 到 1.0 渐变，看起来像一条拖尾。clearRect每帧清空画布是必须的，不然上一帧的内容会叠在上面，转起来就是一团糊。
4.4 让旋转更有质感的几个参数
上面那份代码能跑，但看起来比较朴素。想让圈转得更有质感，可以调这几个地方：
点的半径做变化。让每个点的大小随角度变化，比如dotRadius * (0.5 + 0.5 * Math.sin(rad))，这样圈上会有一个“鼓包”在转，视觉上更有动感。
颜色做渐变。不要用单一颜色，用 HSL 色相随角度变化：hsl(${dotAngle % 360}, 70%, 60%)，转起来就是彩虹环。
加一层底环。在点下面画一个半透明的完整圆环，让旋转的点有参照物，视觉上更稳。
用阴影做发光。ctx.shadowBlur和ctx.shadowColor能给点加上光晕，但要注意性能，阴影是 Canvas 里比较贵的操作，元素多了会掉帧。
这几个参数我建议一个一个加，每加一个看一眼效果，不要一次性全堆上去，不然出了问题不知道是哪个参数导致的。
5. 性能优化：让圈在低端设备上也转得顺
5.1 帧率不稳的常见原因
旋转动画最怕的就是卡顿。我排查过很多次，原因基本集中在三个地方：绘制操作太多、每帧创建对象、画布尺寸过大。
绘制操作太多很好理解，每帧画几百个元素，GPU 再强也扛不住。解决办法是减少元素数量，或者用离屏画布把静态部分缓存起来。每帧创建对象是指像new Path2D()、ctx.createLinearGradient()这种操作如果放在循环里，每帧都创建新对象，垃圾回收压力会很大。解决办法是把能复用的对象提到循环外面。
画布尺寸过大是个隐蔽的坑。有人为了清晰，把画布设成 2000×2000，但实际显示只有 300×300。多出来的像素每帧都要清空和重绘，纯属浪费。画布尺寸应该等于显示尺寸乘以 dpr，不要更大。
5.2 离屏画布缓存静态内容
如果你的圈有一层不动的底环，或者背景有复杂的纹理，可以用离屏画布把它们缓存起来，每帧只画一次drawImage，而不是重新绘制所有细节。
const offscreen = document.createElement('canvas'); const offCtx = offscreen.getContext('2d'); offscreen.width = size * dpr; offscreen.height = size * dpr; offCtx.scale(dpr, dpr); // 在离屏画布上画一次静态内容 offCtx.beginPath(); offCtx.arc(cx, cy, radius + 10, 0, Math.PI * 2); offCtx.strokeStyle = 'rgba(80, 160, 255, 0.1)'; offCtx.lineWidth = 2; offCtx.stroke(); // 主循环里直接贴图 ctx.drawImage(offscreen, 0, 0, size, size);这个技巧在静态内容复杂的时候效果特别明显。我做过一个带刻度线和数字的仪表盘，用离屏缓存之后帧率从 40 提到了稳定 60。
5.3 控制元素数量的经验值
到底画多少个点合适？我的经验是：普通设备上，100 个以内的绘制单元基本无压力；200 个开始要留意；超过 500 个就要考虑优化了。这个数字不是死的，跟每个单元的绘制复杂度有关。画小圆点比画带阴影的复杂图形轻得多。
如果你确实需要很多元素，比如做一个粒子旋转环，那可以考虑用ImageData直接操作像素，或者用 WebGL。但那是另一个量级的工作量了，对于“旋转的圈”这个需求，Canvas 2D 完全够用。
6. 常见问题与排查实录
6.1 圈转起来一顿一顿的
这是最常见的问题。排查顺序是这样的：先看requestAnimationFrame是不是被正确调用了，有没有在循环里做耗时操作。然后检查deltaTime的计算，如果lastTime没有正确更新，增量会忽大忽小。最后看绘制操作，是不是每帧都在创建新对象。
我遇到过一次，原因是clearRect的参数写错了，只清了画布的一部分，导致旧内容残留，看起来像卡顿。这种问题用console.log打帧间隔时间就能定位，正常应该是 16.7ms 左右，如果忽高忽低就是有问题。
6.2 高分屏上模糊
前面说过，是 dpr 适配没做。检查canvas.width是不是等于displaySize * dpr，ctx.scale(dpr, dpr)有没有调用。还有一个容易漏的点：如果画布尺寸在运行时改变了，需要重新设置width和height并重新scale，否则缩放会累积。
6.3 旋转中心不对
圈没有绕着自己中心转，而是绕画布中心或者别的地方转。检查cx和cy是不是设成了画布中心，而radius是不是从圆心算起的。如果你想让圈绕画布中心转，那cx和cy就是size / 2。如果圈本身有偏移，需要把偏移量加到坐标计算里。
6.4 页面切到后台再回来，圈跳了一下
这是因为requestAnimationFrame在页面不可见时会暂停，回来时currentTime跳了一大截，deltaTime变得很大，角度一下增加很多。解决办法是给deltaTime设一个上限，比如最大 0.1 秒：
const deltaTime = Math.min((currentTime - lastTime) / 1000, 0.1);这样即使页面切走很久，回来时圈也不会跳。这个细节很多教程不讲，但实际项目中一定会遇到。
6.5 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方向 |
|---|---|---|---|
| 转起来卡顿 | 帧率不稳/绘制过重 | 打帧间隔日志 | 减少元素/离屏缓存 |
| 画面模糊 | dpr 未适配 | 检查 canvas.width | 乘 dpr 并 scale |
| 旋转中心偏移 | cx/cy 设置错误 | 打印圆心坐标 | 修正圆心或半径 |
| 切后台回来跳帧 | deltaTime 过大 | 打印 deltaTime | 设上限 0.1s |
| 颜色叠加变糊 | 未清空画布 | 检查 clearRect | 每帧清空 |
| 元素多了掉帧 | 绘制单元过多 | 逐步减少数量 | 控制 200 以内 |
7. 这个圈还能怎么玩
基础版跑通之后，可扩展的方向其实挺多的。我列几个我实际做过或者见过效果不错的：
环形进度条。把旋转的圈和进度结合，用arc的起始角和结束角控制弧长，旋转的部分做成头部的小圆点。这个在数据可视化里特别常用，加载、上传、完成度都能用。
多层反向旋转。画两到三层圈，每层转速不同、方向相反，叠在一起有齿轮咬合的感觉。层数不要超过三层，多了会乱。
交互响应。监听鼠标位置，让圈的转速或者方向跟着鼠标变。比如鼠标在左边时逆时针转，在右边时顺时针转，转速跟距离挂钩。这个做出来很有参与感。
粒子拖尾。不用固定的点，而是每帧在圆上随机位置生成粒子，粒子有生命周期，逐渐淡出。这样圈看起来像在甩出火花，适合做加载动画。
文字环绕。把点换成文字，每个字旋转到对应角度，整体转起来就是文字环绕效果。注意每个字要单独save、translate、rotate、fillText、restore，不然文字方向会乱。
这些扩展的共同点是：核心的旋转逻辑不变，只是改变每个绘制单元的样式和位置计算。把基础骨架搭好之后，换样式就是改几行代码的事。
我个人在实际操作中的体会是，Canvas 动画这东西，看十篇教程不如自己动手写一遍。很多坑只有跑起来才会遇到，比如 dpr 模糊、切后台跳帧、清空画布这些，文档里不会特意强调，但实际项目中一个都躲不掉。建议你先把上面那份骨架代码复制到本地跑起来，然后一个一个改参数，看效果怎么变。改着改着，你就知道每个参数是干什么的了。
最后再分享一个小技巧：调试 Canvas 动画的时候，把requestAnimationFrame暂时换成setTimeout，帧率降到 10fps 左右，这样每一帧的变化看得清清楚楚，方便定位坐标和角度的问题。调好了再换回去。这个法子我用了很多次，比盯着 60fps 的画面瞎猜高效多了。
