简介这份PDF资料面向JavaScript初学者与对算法感兴趣的开发者围绕微信抢红包这一经典场景讲解如何用JS模拟实现红包分配算法并解决其中的公平性与精度问题。内容从最朴素的随机函数入手剖析先抢者占优、后抢者金额受限的不公平现象进而引入二倍均值法通过将每次随机区间控制在平均值的一半到两倍之间使各人机会趋于均等同时兼顾每人至少0.01元、总额恰好等于100元的约束。文中还专门讨论了JavaScript浮点数运算导致的余额偏差问题并给出四舍五入等处理思路配有可直接运行的代码示例与测试结果。资源包为1个PDF文件大小约111KB轻量便携适合随时查阅。目前已有452人学习可作为理解随机分配算法、练习JS数值处理的实用参考帮助读者掌握从问题发现到方案优化的完整思路。1. 拆开红包那一刻服务端到底算了什么群里抢红包的场景你一定不陌生手指点下去金额跳出来有人 0.58 有人 12.36最后一个还常常是「手气最佳」。很多人第一次写红包算法直觉是「随机分一下不就行了」结果上线后被用户投诉「每次都抢到几分钱」「大额永远在前面被抢走」。JavaScript 实现微信红包算法及问题解决方法核心其实不是「随机」而是在总额固定、人数固定、每人至少一分钱的前提下让金额分布看起来自然同时保证任何并发情况下总额不超发、不欠发。这篇文章面向的是需要在前端或 Node.js 服务端落地红包逻辑的开发者。我会把「二倍均值法」这个主流思路拆到能直接抄的程度再讲清楚浮点误差、并发超发、金额边界这三个最容易翻车的地方。读完你能自己写出一版可复现、可测试、能扛住并发的红包分配函数而不是只会背一句「随机区间是剩余均值两倍」。2. 二倍均值法为什么它比纯随机更像「真红包」2.1 纯随机的两个致命问题先看最朴素的写法每次从剩余金额里随机取一个数。假设总额 100 元、10 个人第一次随机可能取到 99 元剩下 9 个人分 1 元后面每个人只能拿 0.11 元左右。这种分布在数学上叫「不均匀到极端」用户体验就是「前面的人吃肉后面的人喝汤」。第二个问题是边界失控。如果随机范围是[0, 剩余金额]理论上某一次可以取到接近全部剩余金额导致后面的人分不到钱。要保证每人至少 0.01 元就必须给后续每个人预留 0.01 元也就是当前最大可取值是剩余金额 - (剩余人数 - 1) * 0.01。纯随机不是不能用而是需要额外约束写起来反而更绕。主流做法直接换成二倍均值法。2.2 二倍均值法的数学直觉二倍均值法的规则只有一句话每次随机的范围是[0.01, 剩余金额 / 剩余人数 * 2]取一个随机数作为当前红包金额。为什么是 2 倍因为如果每次都在[0, 剩余均值]里取期望是剩余均值的一半会导致金额越来越小、分布偏斜。取[0, 2倍均值]时期望正好等于剩余均值长期看每个人的期望金额相同分布更接近真实红包的「有高有低但不会太离谱」。举个具体数字100 元 10 人第一次均值 10 元随机范围[0.01, 20]假设取到 15剩 85 元 9 人均值 9.44范围[0.01, 18.89]以此类推。你会发现大额不一定出现在第一个也可能出现在中间这就是「手气最佳」随机性的来源。2.3 用 JavaScript 写出第一版可运行代码下面这版是能直接跑的我把它写成纯函数方便你复制到任何环境测试。/** * 二倍均值法拆分红包 * param {number} total 总金额单位分 * param {number} count 红包个数 * returns {number[]} 每个红包的金额单位分 */ function splitRedPacket(total, count) { // 参数校验总额和个数必须是正整数且总额至少能覆盖每人一分 if (!Number.isInteger(total) || !Number.isInteger(count)) { throw new Error(total 和 count 必须是整数单位分); } if (count 0) { throw new Error(红包个数必须大于 0); } if (total count) { throw new Error(总金额不足以每人至少一分); } const result []; let restAmount total; // 剩余金额单位分 let restCount count; // 剩余人数 while (restCount 1) { // 当前最大可取值 剩余金额 - 给后面每人预留 1 分 const max restAmount - (restCount - 1); // 二倍均值上限但不能超过 max const upper Math.min(Math.floor((restAmount / restCount) * 2), max); // 随机区间 [1, upper]单位分 const amount Math.floor(Math.random() * (upper - 1 1)) 1; result.push(amount); restAmount - amount; restCount - 1; } // 最后一个人拿走剩余全部保证总额精确 result.push(restAmount); return result; } // 测试100 元 10 人 const packets splitRedPacket(10000, 10); console.log(packets); console.log(总额校验, packets.reduce((a, b) a b, 0));逻辑说明整个循环里restAmount和restCount同步递减每次只处理「当前这个人拿多少」最后一个人直接兜底。upper用Math.min做了双重约束既不超过二倍均值也不超过「给后面留够一分钱」的硬上限。参数说明total和count都要求整数单位是分。这是血泪经验——用元做浮点运算后面必然遇到0.1 0.2 ! 0.3的问题。Math.floor保证取整Math.random()返回[0, 1)乘上区间长度再加 1 得到[1, upper]的整数。2.4 为什么单位要用「分」而不是「元」JavaScript 的 Number 是双精度浮点0.1 0.2得到0.30000000000000004。红包金额如果全程用元累加校验时经常出现「总额差一分」的玄学问题。把单位统一成分所有运算都是整数reduce求和必然精确等于total。如果你必须对外返回元只在最后一步除以 100并且用toFixed(2)格式化。注意toFixed返回的是字符串别拿它继续参与运算。3. 把算法接进业务并发、幂等与预分配3.1 并发抢红包为什么会超发上面的函数是「抢的时候现算」。如果 10 个人同时请求每个请求都读到「剩余 100 元 10 人」各自算出一个金额最后总额可能变成 200 元。这就是典型的读-算-写竞态。常见做法有两种。第一种是预分配红包创建时就把 10 个金额算好存进一个列表抢的时候用原子操作弹出。第二种是加锁抢的瞬间对红包记录加行锁或分布式锁算完再释放。预分配更适合高并发因为抢的动作变成了一次pop没有计算过程。3.2 预分配版本的实现/** * 预分配红包创建时算好所有金额 * param {number} total 总金额单位分 * param {number} count 个数 * returns {number[]} 打乱后的金额列表 */ function preSplit(total, count) { const list splitRedPacket(total, count); // 打乱顺序避免「先抢的金额一定大」的规律被用户察觉 for (let i list.length - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)); [list[i], list[j]] [list[j], list[i]]; } return list; } // 模拟并发弹出用数组模拟队列 const queue preSplit(10000, 10); function grab() { if (queue.length 0) return null; return queue.shift(); // 真实环境用 Redis LPOP 或数据库原子更新 }逻辑说明preSplit先调用核心算法再做一次 Fisher-Yates 洗牌。洗牌这步很关键——二倍均值法生成的序列本身有「前大后小」的轻微趋势不打乱的话先抢的人平均拿得更多容易被用户总结出规律。参数说明洗牌循环从后往前j的范围是[0, i]保证每个位置被交换的概率相等。真实业务里queue应该放在 Redis 的 List 或数据库里用LPOP这类原子命令弹出避免应用层并发问题。3.3 幂等同一个人不能抢两次并发之外还有重复请求。用户手抖点两下或者网络重试同一个用户可能拿到两个红包。解决办法是在抢红包的入口做唯一约束用红包ID 用户ID作为唯一键插入成功才继续插入冲突直接返回已抢过的结果。// 伪代码数据库唯一索引兜底 async function grabRedPacket(packetId, userId) { try { // 唯一索引 (packet_id, user_id)重复插入会抛错 await db.insert(red_packet_record, { packet_id: packetId, user_id: userId }); } catch (e) { if (e.code DUPLICATE_ENTRY) { return await db.findOne(red_packet_record, { packet_id: packetId, user_id: userId }); } throw e; } // 插入成功后再执行弹出金额的逻辑 return await popAmount(packetId); }逻辑说明把「记录用户已抢」放在「弹出金额」之前利用数据库唯一索引做幂等。即使两个请求同时到达也只有一个能插入成功另一个走冲突分支返回已有记录。参数说明packet_id和user_id的联合唯一索引是这套方案的核心没有它幂等就不成立。注意插入和弹出金额之间如果服务崩溃会出现「有记录没金额」的状态生产环境需要用事务或补偿任务处理。4. 避坑指南金额、边界与测试的五个翻车现场4.1 坑一浮点误差导致总额差一分现象用元做单位10 个红包加起来是 99.99 或 100.01对账永远对不上。原因0.1 0.2 ! 0.3浮点累加误差在多次运算后放大。解决全程用分做整数运算只在展示层除以 100。如果历史数据已经是元用Math.round(x * 100)转成分再算。4.2 坑二随机上限算错最后一个人拿到负数现象偶尔最后一个红包金额是 0 或负数。原因upper没有用max约束某次随机取到了超过「剩余金额 - 剩余人数」的值导致后面不够分。解决upper Math.min(二倍均值, restAmount - (restCount - 1))两个上限都要卡。测试时把total设成count每人正好一分跑一万次看是否每次都返回全 1。4.3 坑三Math.random 的区间写错永远取不到上限现象金额分布偏小最大值总是差一点。原因Math.random() * upper得到[0, upper)取不到upper如果写成Math.random() * upper 1又可能超过upper。解决要取[1, upper]的整数正确写法是Math.floor(Math.random() * upper) 1。注意这里upper已经是最大值乘upper得到[0, upper)加 1 后是[1, upper]。4.4 坑四并发下预分配列表被重复消费现象两个人抢到同一个金额或者总额超发。原因应用层用普通数组shift()多个进程或线程同时操作没有原子性。解决把列表放到 Redis用LPOP或者数据库里用UPDATE ... WHERE status unused LIMIT 1这类原子更新。应用层内存队列只适合单进程测试。4.5 坑五没做金额下限校验出现 0 元红包现象用户抢到 0.00 元投诉「假红包」。原因随机下限写成了 0或者取整时Math.floor把 0.9 分变成了 0。解决下限固定为 1 分取整用Math.floor后加 1保证最小是 1。测试用例里必须包含total count的极端情况。5. 验证与调优用统计眼光看你的红包分布写完算法别急着上线先跑一批数据看分布。我一般会做三件事总额校验、均值校验、极值校验。// 跑 10000 次统计分布特征 function stressTest(total, count, times) { let min Infinity, max -Infinity, sum 0; for (let i 0; i times; i) { const packets splitRedPacket(total, count); const s packets.reduce((a, b) a b, 0); if (s ! total) throw new Error(总额校验失败 s); min Math.min(min, ...packets); max Math.max(max, ...packets); sum s; } console.log(总额恒等于, total); console.log(历史最小金额, min, 分); console.log(历史最大金额, max, 分); console.log(平均总额, sum / times); } stressTest(10000, 10, 10000);这段代码的价值在于s ! total一旦触发说明你的整数运算有漏洞min如果出现 0说明下限没卡住max如果接近total说明二倍均值上限失效。跑一万次不报错基本可以认为算法层面是稳的。调优方向有两个。如果觉得金额太平均可以把二倍均值改成 1.5 倍或 2.5 倍倍数越大方差越大如果觉得大额太集中可以在预分配后做分段洗牌而不是全局洗牌。参数没有标准答案取决于你的业务想要「刺激」还是「温和」。最后说个我自己的习惯每次改完红包算法我都会把total count、count 1、total极大这三种边界各跑一遍再跑一次一万次压力测试。红包这东西用户对金额的敏感度远超你的想象差一分钱都能被截图发出来。希望帮到你。本文还有配套的精品资源点击获取
简介这份PDF资料面向JavaScript初学者与对算法感兴趣的开发者围绕微信抢红包这一经典场景讲解如何用JS模拟实现红包分配算法并解决其中的公平性与精度问题。内容从最朴素的随机函数入手剖析先抢者占优、后抢者金额受限的不公平现象进而引入二倍均值法通过将每次随机区间控制在平均值的一半到两倍之间使各人机会趋于均等同时兼顾每人至少0.01元、总额恰好等于100元的约束。文中还专门讨论了JavaScript浮点数运算导致的余额偏差问题并给出四舍五入等处理思路配有可直接运行的代码示例与测试结果。资源包为1个PDF文件大小约111KB轻量便携适合随时查阅。目前已有452人学习可作为理解随机分配算法、练习JS数值处理的实用参考帮助读者掌握从问题发现到方案优化的完整思路。1. 拆开红包那一刻服务端到底算了什么群里抢红包的场景你一定不陌生手指点下去金额跳出来有人 0.58 有人 12.36最后一个还常常是「手气最佳」。很多人第一次写红包算法直觉是「随机分一下不就行了」结果上线后被用户投诉「每次都抢到几分钱」「大额永远在前面被抢走」。JavaScript 实现微信红包算法及问题解决方法核心其实不是「随机」而是在总额固定、人数固定、每人至少一分钱的前提下让金额分布看起来自然同时保证任何并发情况下总额不超发、不欠发。这篇文章面向的是需要在前端或 Node.js 服务端落地红包逻辑的开发者。我会把「二倍均值法」这个主流思路拆到能直接抄的程度再讲清楚浮点误差、并发超发、金额边界这三个最容易翻车的地方。读完你能自己写出一版可复现、可测试、能扛住并发的红包分配函数而不是只会背一句「随机区间是剩余均值两倍」。2. 二倍均值法为什么它比纯随机更像「真红包」2.1 纯随机的两个致命问题先看最朴素的写法每次从剩余金额里随机取一个数。假设总额 100 元、10 个人第一次随机可能取到 99 元剩下 9 个人分 1 元后面每个人只能拿 0.11 元左右。这种分布在数学上叫「不均匀到极端」用户体验就是「前面的人吃肉后面的人喝汤」。第二个问题是边界失控。如果随机范围是[0, 剩余金额]理论上某一次可以取到接近全部剩余金额导致后面的人分不到钱。要保证每人至少 0.01 元就必须给后续每个人预留 0.01 元也就是当前最大可取值是剩余金额 - (剩余人数 - 1) * 0.01。纯随机不是不能用而是需要额外约束写起来反而更绕。主流做法直接换成二倍均值法。2.2 二倍均值法的数学直觉二倍均值法的规则只有一句话每次随机的范围是[0.01, 剩余金额 / 剩余人数 * 2]取一个随机数作为当前红包金额。为什么是 2 倍因为如果每次都在[0, 剩余均值]里取期望是剩余均值的一半会导致金额越来越小、分布偏斜。取[0, 2倍均值]时期望正好等于剩余均值长期看每个人的期望金额相同分布更接近真实红包的「有高有低但不会太离谱」。举个具体数字100 元 10 人第一次均值 10 元随机范围[0.01, 20]假设取到 15剩 85 元 9 人均值 9.44范围[0.01, 18.89]以此类推。你会发现大额不一定出现在第一个也可能出现在中间这就是「手气最佳」随机性的来源。2.3 用 JavaScript 写出第一版可运行代码下面这版是能直接跑的我把它写成纯函数方便你复制到任何环境测试。/** * 二倍均值法拆分红包 * param {number} total 总金额单位分 * param {number} count 红包个数 * returns {number[]} 每个红包的金额单位分 */ function splitRedPacket(total, count) { // 参数校验总额和个数必须是正整数且总额至少能覆盖每人一分 if (!Number.isInteger(total) || !Number.isInteger(count)) { throw new Error(total 和 count 必须是整数单位分); } if (count 0) { throw new Error(红包个数必须大于 0); } if (total count) { throw new Error(总金额不足以每人至少一分); } const result []; let restAmount total; // 剩余金额单位分 let restCount count; // 剩余人数 while (restCount 1) { // 当前最大可取值 剩余金额 - 给后面每人预留 1 分 const max restAmount - (restCount - 1); // 二倍均值上限但不能超过 max const upper Math.min(Math.floor((restAmount / restCount) * 2), max); // 随机区间 [1, upper]单位分 const amount Math.floor(Math.random() * (upper - 1 1)) 1; result.push(amount); restAmount - amount; restCount - 1; } // 最后一个人拿走剩余全部保证总额精确 result.push(restAmount); return result; } // 测试100 元 10 人 const packets splitRedPacket(10000, 10); console.log(packets); console.log(总额校验, packets.reduce((a, b) a b, 0));逻辑说明整个循环里restAmount和restCount同步递减每次只处理「当前这个人拿多少」最后一个人直接兜底。upper用Math.min做了双重约束既不超过二倍均值也不超过「给后面留够一分钱」的硬上限。参数说明total和count都要求整数单位是分。这是血泪经验——用元做浮点运算后面必然遇到0.1 0.2 ! 0.3的问题。Math.floor保证取整Math.random()返回[0, 1)乘上区间长度再加 1 得到[1, upper]的整数。2.4 为什么单位要用「分」而不是「元」JavaScript 的 Number 是双精度浮点0.1 0.2得到0.30000000000000004。红包金额如果全程用元累加校验时经常出现「总额差一分」的玄学问题。把单位统一成分所有运算都是整数reduce求和必然精确等于total。如果你必须对外返回元只在最后一步除以 100并且用toFixed(2)格式化。注意toFixed返回的是字符串别拿它继续参与运算。3. 把算法接进业务并发、幂等与预分配3.1 并发抢红包为什么会超发上面的函数是「抢的时候现算」。如果 10 个人同时请求每个请求都读到「剩余 100 元 10 人」各自算出一个金额最后总额可能变成 200 元。这就是典型的读-算-写竞态。常见做法有两种。第一种是预分配红包创建时就把 10 个金额算好存进一个列表抢的时候用原子操作弹出。第二种是加锁抢的瞬间对红包记录加行锁或分布式锁算完再释放。预分配更适合高并发因为抢的动作变成了一次pop没有计算过程。3.2 预分配版本的实现/** * 预分配红包创建时算好所有金额 * param {number} total 总金额单位分 * param {number} count 个数 * returns {number[]} 打乱后的金额列表 */ function preSplit(total, count) { const list splitRedPacket(total, count); // 打乱顺序避免「先抢的金额一定大」的规律被用户察觉 for (let i list.length - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)); [list[i], list[j]] [list[j], list[i]]; } return list; } // 模拟并发弹出用数组模拟队列 const queue preSplit(10000, 10); function grab() { if (queue.length 0) return null; return queue.shift(); // 真实环境用 Redis LPOP 或数据库原子更新 }逻辑说明preSplit先调用核心算法再做一次 Fisher-Yates 洗牌。洗牌这步很关键——二倍均值法生成的序列本身有「前大后小」的轻微趋势不打乱的话先抢的人平均拿得更多容易被用户总结出规律。参数说明洗牌循环从后往前j的范围是[0, i]保证每个位置被交换的概率相等。真实业务里queue应该放在 Redis 的 List 或数据库里用LPOP这类原子命令弹出避免应用层并发问题。3.3 幂等同一个人不能抢两次并发之外还有重复请求。用户手抖点两下或者网络重试同一个用户可能拿到两个红包。解决办法是在抢红包的入口做唯一约束用红包ID 用户ID作为唯一键插入成功才继续插入冲突直接返回已抢过的结果。// 伪代码数据库唯一索引兜底 async function grabRedPacket(packetId, userId) { try { // 唯一索引 (packet_id, user_id)重复插入会抛错 await db.insert(red_packet_record, { packet_id: packetId, user_id: userId }); } catch (e) { if (e.code DUPLICATE_ENTRY) { return await db.findOne(red_packet_record, { packet_id: packetId, user_id: userId }); } throw e; } // 插入成功后再执行弹出金额的逻辑 return await popAmount(packetId); }逻辑说明把「记录用户已抢」放在「弹出金额」之前利用数据库唯一索引做幂等。即使两个请求同时到达也只有一个能插入成功另一个走冲突分支返回已有记录。参数说明packet_id和user_id的联合唯一索引是这套方案的核心没有它幂等就不成立。注意插入和弹出金额之间如果服务崩溃会出现「有记录没金额」的状态生产环境需要用事务或补偿任务处理。4. 避坑指南金额、边界与测试的五个翻车现场4.1 坑一浮点误差导致总额差一分现象用元做单位10 个红包加起来是 99.99 或 100.01对账永远对不上。原因0.1 0.2 ! 0.3浮点累加误差在多次运算后放大。解决全程用分做整数运算只在展示层除以 100。如果历史数据已经是元用Math.round(x * 100)转成分再算。4.2 坑二随机上限算错最后一个人拿到负数现象偶尔最后一个红包金额是 0 或负数。原因upper没有用max约束某次随机取到了超过「剩余金额 - 剩余人数」的值导致后面不够分。解决upper Math.min(二倍均值, restAmount - (restCount - 1))两个上限都要卡。测试时把total设成count每人正好一分跑一万次看是否每次都返回全 1。4.3 坑三Math.random 的区间写错永远取不到上限现象金额分布偏小最大值总是差一点。原因Math.random() * upper得到[0, upper)取不到upper如果写成Math.random() * upper 1又可能超过upper。解决要取[1, upper]的整数正确写法是Math.floor(Math.random() * upper) 1。注意这里upper已经是最大值乘upper得到[0, upper)加 1 后是[1, upper]。4.4 坑四并发下预分配列表被重复消费现象两个人抢到同一个金额或者总额超发。原因应用层用普通数组shift()多个进程或线程同时操作没有原子性。解决把列表放到 Redis用LPOP或者数据库里用UPDATE ... WHERE status unused LIMIT 1这类原子更新。应用层内存队列只适合单进程测试。4.5 坑五没做金额下限校验出现 0 元红包现象用户抢到 0.00 元投诉「假红包」。原因随机下限写成了 0或者取整时Math.floor把 0.9 分变成了 0。解决下限固定为 1 分取整用Math.floor后加 1保证最小是 1。测试用例里必须包含total count的极端情况。5. 验证与调优用统计眼光看你的红包分布写完算法别急着上线先跑一批数据看分布。我一般会做三件事总额校验、均值校验、极值校验。// 跑 10000 次统计分布特征 function stressTest(total, count, times) { let min Infinity, max -Infinity, sum 0; for (let i 0; i times; i) { const packets splitRedPacket(total, count); const s packets.reduce((a, b) a b, 0); if (s ! total) throw new Error(总额校验失败 s); min Math.min(min, ...packets); max Math.max(max, ...packets); sum s; } console.log(总额恒等于, total); console.log(历史最小金额, min, 分); console.log(历史最大金额, max, 分); console.log(平均总额, sum / times); } stressTest(10000, 10, 10000);这段代码的价值在于s ! total一旦触发说明你的整数运算有漏洞min如果出现 0说明下限没卡住max如果接近total说明二倍均值上限失效。跑一万次不报错基本可以认为算法层面是稳的。调优方向有两个。如果觉得金额太平均可以把二倍均值改成 1.5 倍或 2.5 倍倍数越大方差越大如果觉得大额太集中可以在预分配后做分段洗牌而不是全局洗牌。参数没有标准答案取决于你的业务想要「刺激」还是「温和」。最后说个我自己的习惯每次改完红包算法我都会把total count、count 1、total极大这三种边界各跑一遍再跑一次一万次压力测试。红包这东西用户对金额的敏感度远超你的想象差一分钱都能被截图发出来。希望帮到你。本文还有配套的精品资源点击获取
