必须用 transform + opacity 实现流星动画，因其硬件加速且不触发重排；left/top 会导致卡顿，background-position 难以精准控制轨迹；需错开 delay/duration、限制 DOM 数量、禁用 blur/box-shadow 等性能杀手。
纯 CSS 实现“星空背景 + 流星划过”效果，关键不是堆动画数量，而是让流星真正「飞起来」且不拖垮页面。用 transform 位移 + opacity 变化是最稳的组合，left/top 或 background-position 都会触发重排或性能掉帧。
为什么必须用 transform + opacity，而不是 left/top 或 background
浏览器对 transform 和 opacity 的动画做了硬件加速优化，只要不改布局、不触重排，就能稳定 60fps；而 left、top 改变的是文档流坐标，每次重绘都要重新计算位置+尺寸+层叠，低端机直接卡顿；background-position 动画虽不重排，但无法精准控制单颗流星起点/角度，且和星空背景混在一起后难以分层管理。
-
transform: translateX()+translateY()组合能干净模拟斜向飞行，配合skewX()比rotate()更可控（不用算旋转中心偏移） -
opacity变化必须是非对称的：比如0.1 → 0.9 → 0.3 → 0.8，避免开关式闪烁 - 禁用
will-change: transform在移动端——iOS Safari 和部分安卓 WebView 会因此图层爆炸甚至白屏
每颗流星必须有独立 animation-delay 和 duration
所有流星共用同一个 animation-delay: 0s，结果就是一排平行线同步飞过，毫无随机感。真实流星出发时间、速度、轨迹长度都不同，CSS 层面只能靠错开动画相位来模拟。
- 用
:nth-child(3n)、:nth-child(5n+2)等选择器批量设不同--delay和--duration自定义属性 - 延迟值推荐用负数（如
-1.3s），让动画从中间帧开始播放，比正延迟更自然 - 时长别全设成 3s，混搭 2.4s / 3.7s / 4.9s，视觉节奏才松紧有度
- 别用
Math.random()在 JS 里动态写style.animationDelay——首屏渲染时未生效，SSR 场景直接失效
DOM 数量要克制，用 requestAnimationFrame 控制生成节奏
同时存在 50+ 个 .meteor 元素，旧版 Chrome 或千元机就掉帧；无脑 setInterval(() => el.insertAdjacentHTML(...)) 会导致内存泄漏和 DOM 膨胀。
立即学习“前端免费学习笔记（深入）”；
- 只保留在视口内或即将进入视口的流星，其余立刻
el.remove() - 监听
animationend事件删除，别用setTimeout延时删——动画被暂停或跳帧时会失准 - 每 300ms 最多新增 1–2 颗流星，用
requestAnimationFrame驱动，避免阻塞主线程 - 插入前调
el.style.pointerEvents = 'none'，防止流星遮挡下方按钮点击
clip-path 或极小尺寸模拟光点，别加 filter/box-shadow
流星不是发光体，是高速运动的光迹。用 filter: blur() 或 box-shadow 做柔边，在动画中是性能杀手，尤其在低端安卓上帧率直接跌破 10fps。
- 用
width: 2px; height: 2px;+border-radius: 50%就够，高 DPI 屏用px单位，别用rem - 想加光晕？用两层叠加：主干细线 + 一层更宽更淡的同路径元素，靠
opacity控制显隐 -
clip-path: circle(1px)比border-radius渲染开销略低，但兼容性稍差（IE 不支持），可酌情选用 - 禁用
background-color动画——哪怕只是渐变，也会让浏览器放弃合成优化
真正难的不是写出几段 @keyframes，而是控制好流星的「生命周期」：什么时候生成、飞到哪该删、有多少颗同时在飞、怎么不抢主线程资源。这些细节没压住，再炫的动画也撑不过三秒。
