CSS变量用于高频粒子轨迹会卡顿，因每帧JS更新触发样式计算与合成开销；超30个粒子应改用canvas/WebGL；推荐JS直接操作style.transform，CSS变量仅用于全局参数如时间偏移或缩放。
为什么直接用 CSS 变量做粒子轨迹会卡顿
CSS 自定义属性本身不触发重排，但一旦用于 transform 或 background-position 等需频繁重绘的属性，且由 JS 每帧更新（如 requestAnimationFrame），浏览器就得反复解析变量、计算样式、合成图层。尤其当粒子数超 50 个，element.style.setProperty('--x', x + 'px') 的调用开销会明显拖慢帧率。
- 粒子数量 > 30 时，优先考虑
canvas或WebGL，CSS 方案仅适合示意或低密度动效 - 不要对每个粒子 DOM 元素单独设变量；改用单个
:root变量 +calc()表达式批量驱动（见下条） - 避免在变量中存带单位的值（如
--x: 120px），JS 更新时拼字符串易出错；统一存纯数字，CSS 侧用calc(var(--x) * 1px)
如何用一个 :root 变量驱动多个粒子位移
核心思路：把所有粒子的坐标序列化为字符串（如 "10,45,82,130,..."），存进单个 --positions 变量，再用 CSS clip-path 或 mask-image 结合 conic-gradient 等技巧“解包”——但这太绕且兼容性差。更实用的是用 transform: translate(calc(...), calc(...)) 配合伪元素定位。
实际推荐做法是：
- 用 JS 生成一组
transform值（如translate(120px, 80px)），直接写入元素的style.transform - 若坚持用 CSS 变量，只用于控制全局时间偏移或缩放系数等少数高复用参数，例如：
:root { --t: 0; --scale: 1.2; }然后每个粒子用
transform: translate(calc(var(--t) <em> 2px), calc(var(--t) </em> -1.5px)) scale(var(--scale));立即学习“前端免费学习笔记（深入）”；
JS 批量更新变量的正确节奏
requestAnimationFrame 是必须的，但别在每帧里遍历所有粒子调 setProperty。实测发现，合并成一次 CSSStyleSheet.insertRule 或用 style.cssText 批量写入更快：
- 把所有粒子的
--x/--y值拼成一段 CSS 字符串：const cssText = <code>.particle:nth-child(1) { --x: ${x1}; --y: ${y1}; } .particle:nth-child(2) { --x: ${x2}; --y: ${y2}; }</code>; - 写入
document.styleSheets[0].cssRules（需先创建空<style>并 append） - 更稳妥的做法：用
document.documentElement.style.cssText += <code>--x1:${x1};--y1:${y1};--x2:${x2};--y2:${y2};，然后在 CSS 中用var(--x1)等引用 - 注意：Chrome 对
cssText追加有长度限制（约 100KB），粒子超 200 个就可能截断
真正能跑顺的最小可行结构
别试图让 CSS 变量承担轨迹计算。把运动逻辑全交给 JS，CSS 只做呈现：
- 粒子用
position: absolute，JS 直接改el.style.left和el.style.top（开启will-change: transform提升图层） - 或统一用
transform: translate(x, y)，JS 改el.style.transform—— 这比变量快 3~5 倍 - 如果必须用变量（比如要配合 CSS 动画过渡），只对「起始/终止」两帧设变量，中间用
@keyframes插值，而非 JS 每帧推
CSS 变量适合静态配置或低频开关，高频坐标更新本质是 JS 任务。硬套变量反而增加解析负担，还容易因单位、作用域、继承顺序出错。
