100万粒子能否稳达60fps取决于是否绕开主线程阻塞、内存抖动和无效绘制三大瓶颈；需采用offscreencanvas+web worker解耦计算与渲染，结合粒子池化、分组批量绘制及webgl加速，canvas 2d仅12fps而webgl可达28fps。
Canvas 渲染大规模粒子时，性能瓶颈往往不是“画不出来”，而是“算不过来、管不住、画太多”。真正卡住帧率的，通常是 JavaScript 计算层和渲染调用开销，而非显卡能力本身。100 万粒子能否跑稳 60 FPS，取决于你是否绕开了主线程阻塞、内存抖动和无效绘制这三座大山。
主线程解耦：OffscreenCanvas + Web Worker 是硬门槛
传统 requestAnimationFrame 在主线程里一边算坐标、一边清屏重绘，10 万个粒子的物理更新就可能耗掉 30ms，直接跌破 30 FPS，还导致页面点击无响应。解法很明确：
- 主线程只做 UI 交互（比如监听鼠标、按钮点击），把
canvas.transferControlToOffscreen()后的离屏画布交给 Worker - Worker 线程独占 Canvas 上下文，专注执行粒子运动、碰撞、生命周期判断和 WebGL 绘制
- 使用
postMessage配合 transfer list 实现零拷贝通信，避免序列化开销
粒子管理不靠 new，靠池化与状态筛选
每帧都 new Particle() 再 delete，等于主动邀请垃圾回收器来捣乱。高频创建销毁会让内存占用忽高忽低，引发卡顿。高效做法是：
- 预分配固定数量粒子对象（例如 2000 或 5000 个），全部存入数组，用
isDead标记存活状态 - 发射新粒子时，从池中找一个
isDead === true的对象重置属性（位置、速度、生命值） -
跳过无效更新：静止粒子、出屏粒子、已死亡粒子，一律不进
update()流程 - 用整数帧计数器替代
Date.now()判断生命周期，更稳定、无精度误差
渲染不是“一个个画”，而是“分组批量刷”
Canvas API 调用本身有固定开销。画 1 万个不同颜色的小圆，如果每画一个都改一次 fillStyle、调一次 beginPath 和 fill，性能会断崖式下跌。优化核心是减少状态切换和调用次数：
- 按视觉属性聚类：把同色、同透明度、同尺寸区间的粒子归为一组
- 每组只设置一次
ctx.fillStyle、ctx.globalAlpha，再统一调用beginPath → arc → fill - 对纯色小圆，优先用
fillRect(x-r, y-r, r*2, r*2)替代arc + fill，快 2–3 倍 - 启用空间索引（如网格哈希 Grid Hash），只遍历视口覆盖区域内的粒子桶，候选粒子常不足总数 5%
引擎选型不能拍脑袋：WebGL 不是万能，但 Canvas 2D 有硬上限
测试数据很说明问题：在 100 万粒子场景下，Canvas 2D 模式平均仅 12 FPS，而 WebGL 模式可达 28 FPS——差了两倍多。这不是配置问题，是底层机制差异：
- Canvas 2D 是 CPU 主导的软件渲染，每帧都要在主线程处理路径、填充、合成，粒子一过 5 万就明显吃力
- WebGL 利用 GPU 并行能力，粒子位置、颜色、大小等属性可批量上传为缓冲区，由着色器统一计算与绘制
- 注意：WebGL 初始化略慢（约 0.8s），且需确保浏览器支持；移动端低端设备仍建议 fallback 到 Canvas 2D + 强裁剪
