微信红包金额分配必须由服务端完成，前端JavaScript生成随机数不可信，易被篡改导致资损；服务端应使用安全随机源（如SecureRandom）并采用线段切割法等可靠算法，确保每人≥0.01元、总额精确无浮点误差。
红包金额随机分配必须用服务端生成
前端 JavaScript 生成的随机数不可信，用户可篡改、重放、调试绕过逻辑，导致红包金额被刷或出现负数、超限等异常。所有红包拆分逻辑（包括总金额校验、个数约束、最小单位控制）必须在服务端完成。
常见错误现象：Math.random() 在前端直接算出 0.01～200 元之间不等额红包，结果被 F12 修改后发出去，造成资损。
- 服务端应使用安全随机源（如 Node.js 的
crypto.randomInt()、PHP 的random_int()、Java 的SecureRandom） - 分配算法推荐「线段切割法」：生成 n−1 个 [0, 总金额×100] 区间内的不重复随机整数（单位为分），排序后与 0 和 总金额×100 构成 n 段，每段差值即为红包金额（单位分），最后转回元并保留两位小数
- 必须校验：每人最低 0.01 元（1 分）、所有人之和严格等于总金额（以分为单位做整数加减，避免浮点误差）
微信内 H5 红包点击无响应？检查 JSAPI 权限和域名绑定
在微信浏览器中调用支付或分享等能力前，必须完成 JSAPI 签名认证。拼手气红包虽不直接调起支付，但若后续跳转到支付页、或需调用 updateAppMessageShareData 宣传裂变，则签名失效会导致按钮静默失败。
常见错误现象：点击「拆红包」没反应，控制台无报错，wechat-jssdk 初始化成功但 config:ok 后调用接口返回 invalid signature。
立即学习“前端免费学习笔记（深入）”；
- 确认公众号 JS 接口安全域名已添加当前活动页域名（含协议、端口、路径前缀均需匹配）
- 签名用的
nonceStr和timestamp必须与后端生成签名时一致，不能前端自己生成再传给后端 - 微信 iOS 15+ 和安卓最新版对
location.href跳转拦截更严，如需跳转至支付页，请用WxPay或chooseImage等合法 JSAPI 触发上下文，避免纯 location 跳转被禁
红包雨动画卡顿？别用 setInterval + DOM 操作
H5 拼手气红包常搭配「红包雨」视觉效果，但用 setInterval 频繁创建 div 并设置 top/left/transform，在低端安卓机上极易掉帧甚至白屏。
性能影响明显：100 个红包元素同时做 CSS 动画，触发频繁 layout + paint，GPU 内存溢出风险高。
- 改用
requestAnimationFrame控制帧率，单次最多新增 3～5 个红包元素 - 所有红包 DOM 节点复用：预先创建 20 个
div.redpacket-item放入隐藏容器，动画时只修改style和dataset，不appendChild - 动画属性优先用
transform: translate3d()和opacity，避开top、left、width等触发重排的属性 - 真机测试务必覆盖 Android 8.0～10 的 WebView（如微信内置 X5 内核），X5 对
will-change支持不全，慎用
用户反复点击「开红包」怎么防重？服务端幂等 + 前端锁 UI
手速快的用户连续点 5 下，可能触发多次拆包请求，导致同一个红包被重复领取或并发扣减出错。这不是“体验优化”，是资金安全红线。
容易被忽略的地方：仅前端加 disabled 或 loading 状态不够——网络延迟下用户仍可快速连点，且页面刷新后状态丢失。
- 服务端必须对每个
user_id + redpacket_id + timestamp（或唯一业务流水号）做幂等校验，Redis 中记录已处理的请求 ID，超时时间设为 5 分钟 - 前端在第一次点击后立即置灰按钮，并移除所有事件监听器（不要只靠
disabled，iOS Safari 对 button disabled 样式支持不稳定） - 响应成功后，无论是否中奖，都清空本地缓存的红包状态，避免离线重进时误判
- 注意：微信 JSAPI 的
openProductSpecificView等跳转类接口本身不具备幂等性，必须包裹在你自己的幂等逻辑里
