应使用 requestAnimationFrame 而非 setInterval 实现 Canvas 粒子动画，因其自动适配屏幕刷新率、省资源；需分离更新与绘制逻辑，避免重计算阻塞渲染，并正确处理 DPR 与 canvas 尺寸。
用 requestAnimationFrame 而不是 setInterval
Canvas 粒子动画卡顿、掉帧，八成是因为用了 setInterval 控制刷新。它不跟屏幕刷新率同步，容易跳帧或堆积任务。requestAnimationFrame 才是浏览器原生推荐的动画驱动方式，自动适配 60fps（或设备实际刷新率），还能在标签页不可见时暂停执行，省资源。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把所有动画循环逻辑包进一个函数，比如
animate，然后在函数末尾调用requestAnimationFrame(animate) - 别在
requestAnimationFrame回调里做重计算（如大量粒子位置重生成），优先做渲染；复杂逻辑可拆到单独 tick 函数，并用时间戳控制频率 - 如果需要精确控制帧间隔（比如固定 30fps），用时间差判断，而不是强行节流——
requestAnimationFrame本身不保证帧率，只保证“下一帧”时机
粒子更新和绘制必须分离
常见错误是每帧都重新生成全部粒子对象，或者在绘制循环里同时算物理、碰撞、颜色、透明度……结果一两百个粒子就掉到 20fps。Canvas 渲染慢的主因不是画布本身，而是 JS 计算阻塞了渲染线程。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 粒子数据（
position、velocity、size、alpha）用数组存 plain object 或 TypedArray（如Float32Array），避免频繁创建/销毁对象 - 更新阶段只做数值运算：位置 += 速度，加阻尼，边界反弹等；绘制阶段只调用
ctx.beginPath()→ctx.arc()→ctx.fill() - 如果粒子有生命周期（比如烟花爆炸后消失），用「死亡标记 + 数组重用」比
splice更快；避免在循环中修改数组长度
globalCompositeOperation 用错会吃性能还穿帮
想实现粒子融合、光晕、淡入淡出效果，很多人直接设 ctx.globalCompositeOperation = 'lighter'。这确实能叠加发光，但代价很高：浏览器无法使用图层加速，强制回退到 CPU 合成，尤其在 Safari 和旧版 Chrome 上明显卡顿；而且一旦背景不是纯黑，lighter 会让颜色过曝失真。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 仅在必要时启用
lighter，用完立刻切回source-over（默认值） - 替代方案：用半透明叠加（
fillStyle = 'rgba(255,100,100,0.05)'）模拟余晖，更可控也更快 - 真要高级混合（如 screen、multiply），优先考虑离屏 canvas 预渲染+贴图，而非实时混合——特别是粒子数 > 500 时
移动端 Canvas 尺寸没适配视口，粒子全挤在左上角
写死 canvas.width = 800; canvas.height = 600; 在 PC 浏览器里看着正常，一上手机就缩成小方块，或者模糊拉伸。Canvas 的像素尺寸（width/height 属性）和 CSS 显示尺寸（style.width/style.height）是两回事，不手动同步就会出问题。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
resize，按设备像素比缩放：const dpr = window.devicePixelRatio || 1;，然后设canvas.width = width * dpr，canvas.height = height * dpr，再用 CSS 把显示尺寸设为width: ${width}px; height: ${height}px - 别用
canvas.getBoundingClientRect()直接赋值给width/height，它返回的是 CSS 像素，没乘 DPR - 粒子坐标计算时，统一用「逻辑坐标」（比如 0~100 表示全宽），再乘以 DPR 后绘制，避免不同设备下行为不一致
粒子动画真正难的不是画出来，是让几百个点在各种屏幕、各种负载下都稳住帧率。关键不是堆特效，而是守住那条线：JS 计算够轻、Canvas 操作够直、尺寸逻辑够干净。
