红包雨动画应根据数量和交互需求选择：≤20个用css动画+硬件加速；≥30个或需交互效果则用requestanimationframe+canvas，并做好生命周期管理。
红包雨动画用 CSS 动画还是 requestAnimationFrame？
直接用 CSS @keyframes 实现红包下落最简单，但控制力弱、无法动态调整速度或碰撞逻辑；真要加随机旋转、落地弹跳、点击消失、计数反馈，必须切到 requestAnimationFrame + canvas 或绝对定位 DOM 元素。H5 页面多数跑在低端安卓机上，canvas 渲染 50+ 红包时帧率更稳，DOM 方案容易掉帧甚至卡死。
实操建议：
- 红包数量 ≤ 20 个：用
CSS animation+transform: translate3d()触发硬件加速，每个红包加不同animation-delay和animation-duration - 红包数量 ≥ 30 个，或需点击计数/音效/粒子效果：用
canvas，每帧只 draw 当前存活红包，用对象池复用红包实例，避免频繁 new/delete - 别用
setInterval控制下落——时间精度差，多轮叠加后动画明显拖慢
红包元素怎么生成才不卡顿？
一次性批量生成 100 个 <div class="hongbao">，再逐个 <code>appendChild，会触发多次回流，iOS Safari 尤其明显。关键不是“能不能做”，而是“怎么让浏览器少算布局”。
实操建议：
- 用
document.createDocumentFragment()批量插入，最后一次 append 到 body - 红包 DOM 元素设
position: fixed或absolute，脱离文档流，避免影响其他内容重排 - 禁用
transition和box-shadow（尤其在低端机上，阴影是性能杀手） - 每个红包的
width/height用固定像素值，别用%或vw，减少 layout 计算
点击红包没反应？排查这三处
常见现象：红包飘着，点上去没计数、没音效、没消失。不是逻辑写错了，大概率是事件绑定或层级问题。
实操建议：
- 检查红包元素是否被
pointer-events: none的父容器挡住（比如全屏遮罩层漏写了pointer-events: auto） - 移动端用
touchstart替代click，避免 300ms 延迟导致误判；同时加{ passive: false }防止被浏览器默认忽略 - 红包移出视口后记得调用
element.remove()或回收进池子，否则残留 DOM 会持续响应事件，越积越多越卡
微信内嵌浏览器里动画突然变慢或暂停？
微信 Android 客户端（尤其 v8.0.22 之前）对非可见区域的 requestAnimationFrame 会主动节流，切后台再切回来，动画直接卡住一两秒。这不是 bug，是微信的资源管控策略。
实操建议：
- 监听
visibilitychange事件，页面不可见时暂停动画循环（cancelAnimationFrame），可见时重置时间戳再启动 - 红包下落用「相对时间」而非「绝对帧数」：每次
raf回调里读performance.now()，算本次和上次的时间差来更新位置，避免切后台后补帧爆炸 - 别依赖
Page Visibility API的visible状态做核心逻辑——有些安卓微信根本不抛这个事件，得 fallback 到定时检测document.hidden
红包雨看着热闹，真正难的是在各种机型和微信版本里保持流畅响应。最容易被忽略的，是红包生命周期管理——生成、运动、点击、销毁，每个环节漏掉清理，撑不过三轮活动就内存告警。
