当前位置 & &
& 这是真的！微信抢红包也可能犯法
这是真的！微信抢红包也可能犯法
00:13:19&&出处：&&
编辑：鲲鹏 &&)
让小伙伴们也看看：
阅读更多：
好文共享：
文章观点支持
当前平均分：0(0 次打分)
[09-06][09-06][09-02][09-01][09-01][08-31][08-31][08-31][08-29][08-28]
登录驱动之家
没有帐号？
用合作网站帐户直接登录微信抢红包神器的实现原理是什么？
看到大家回答的都是红包分配的算法，是我问题描述不清吗？我想问的是自动抢红包插件的实现原理啊！
-----------------------------------------------------------------------------------------匿名了。由于比较忙，目前程序已经停止。使用时建议修改包名，否则可能被封杀。没有微信没有qq，不要加我！！！不接外包，多少钱都不接！！！！！！！！！！！！！！！有问题，看完说明文档以及issue再提，不要浪费彼此时间好么？Android基础问题也麻烦百度一下好么，我tm有工作啊，天天解答这种问题闲着蛋疼啊。我装逼，我傻逼，行了吧，满意了吧？-_-有本事自己开源一个啊。以下程序说的是自动完成抢红包而已，自动点击通知栏红包信息，在红包页面自动点开红包。跟豌豆荚的自动装是一个原理。至于其他的透视，红包顺序等无法做到。当然理论上，如果手机root，hook微信api是可行---------------------------UPDATE--------------------------------------------------年前觉得好玩（闲着蛋疼）搞了一个。同意 所说。补充一些，代码层面其实使用的是系统的AccessibilityService，相关资料如下。这个服务是属于系统级别的服务，需要用户手动开启。Google开发这个API的初衷应该是用来帮助障碍人士更方便的使用手机而给开发者预留的。结果被人用来抢红包了。通过相应的API，可以检测到通知栏的通知变动，检测到页面的变化，然后去做相应的操作，比如点击。不过API对系统有限制，目前只有Android 4.4以上才提供页面元素遍历的功能。否则，无法识别红包，也就无法点击了。代码已经开源啦。去试试吧。APK：视频：代码：当然，以上说的是Android版的。UPATE 后来一段时间我想了下其他的实现原理，理论上是没有问题的。1.模拟点击，原理上文已经讲清楚；2.Hook 微信，直接接管红包View事件，需要手机ROOT；3.API模拟，之前我看到有人用Python写过相关的脚本，此有极大概率导致封号；其他具体细节没有研究过，大致方向是没有问题的。由于近期十分忙，不接收私信相关咨询，谢谢。以上，希望对大家有帮助。
都在说怎么用外挂抢红包，我来说一些另类的吧【在被微信封锁的情况下，仍然能领取红包的方法】以下是我的测试号因为使用外挂被封的截图**如何在被微信封锁领红包功能的情况下，仍然能领取红包？****实测成功，只对iOS越狱用户，Android被封的用户可以转用iPhone继续领取红包**1. 【对微信版本进行降级】
测试号是在微信更新不久之后就被封号的，可以推测最新的微信加入了反外挂的方法【检测包名】，实测这个版本的微信可以突破封锁旧版微信下载地址：2. 【改变外挂方式】
相信大部分人都是使用Cydia上的插件《秒抢红包》来实现自动抢红包功能的，但是这个外挂实现原理是模拟点击，是无法突破微信的弹框封锁的，必须使用hook API的方式，绕过联网检测，这里推荐 @ 大神的开源插件，实测没有任何问题 下载地址：附上我成功突破封锁的截图，虽然我们无法打开红包查看领取了多少钱，但是底下仍然会提示我们领取红包成功
过了半年才看到这个贴，再一看其他回答都是Android和http分析，却没有iOS的，于是也来凑个热闹。我写了一个iOS版的插件来给LP抢红包玩，原理很简单，就是在当前群里，监控收到的所有消息类型，一旦发现是红包消息就调用打开红包的api，再顺便把抢红包的动作给完成了。响应时间在2秒内完成，最主要的是：程序自动抢，不用人来干预了。说到底就是hook了微信的api，这些都必须基于越狱的iPhone来做，和之前做Android插件的哥们做法应该是一样的。
我是“关云藏红包神器”开发团队的，用最简单的话来讲吧当你没有屏蔽微信消息并且设置了显示详细消息的情况下，我们每收到一条微信消息，通知栏都会有提示，并且会出现消息的内容，红包也是一样，收到红包消息时我们通知栏也会有提示，我们神器的工作原理就是识别通知栏的消息，当通知栏出现红包的信息码时，神器就工作激活抢红包和语音提示收到红包的功能
年前也无聊写了下，那时用NotificationListenerService来检测，Uiautomator点击，实现起来灰常不优雅。直到我发现关云藏那个东东，然后反编译，才发现AccessibilityService这个神奇的API，思路也是跟赞哥的方法类似，AccessibilityService直接监测通知栏并过滤解析，然后通过API页面跳转，遍历并找到当前界面相应Note节点（按钮）等，触发点击。。。为赞哥的无私开源点赞！！！
通过利用Google官方的辅助功能，写一个service继承AccessibilityService，service中设置android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"&权限，这个service可以监听每个窗口下的控件，开启service去遍历每一个红包节点，发现有红包，即可自动触发button事件
个人猜测有两种可能：1.应该是类似fiddler这样的中间代理器，将腾讯服务器推送过来的socket数据包进行解析分析，当截取到指定关键字段（比如msgtype=hongbao之类的），就模拟提交一次抢红包操作。。。当然实际微信肯定加密过信息的，所以可能性很低。2.不对微信通信进行劫持，而是采用服务绑定的方式，对android的通知事件监控（微信接受到信息会向通知栏发送一个意图，这样我采用某种类屏幕重绘事件钩子之类的方式进行监听，我个人不是好熟悉Android的消息通知机制，但按照普通操作系统的原理，应该可以在未处理事件消息队列中提前提取分析），然后对字符串进行正则匹配到“xx发了一个红包”之类的关键字后，马上调用系统的声音啊，亮屏之类来提醒你。
安卓版本，调用了辅助功能，系统提供的一个服务，首先接收通知匹配是否是微信的，其次模拟用户点击执行抢红包操作，网上有源码，可以去了解
我是搬运工，搬自酷勤网 编者按：2015年微信红包书写了一个全新奇迹——除夕摇一摇总次数110亿次，峰值1400万次/秒，8.1亿次每分钟，微信红包收发达10.1亿次！惊人数字的背后，腾讯是怎么支撑的？笔者有幸节前采访到微信后台技术负责人，与大家分享红包背后的技术。春晚当天，微信红包联合团队彻夜加班全程守护400倍的挑战今年微信红包方式与去年用户与用户之间互发红包相比，摇红包的方式对业务量来说是一个极大的爆发，光是除夕10：30送出的一波红包就达到了1.2亿个，已经是2014年除夕夜峰值的400倍之巨（2014年峰值每分钟被拆开红包数量仅2.5W个）！进入抢红包环节，后台数据瞬间飙升发10亿红包，难在哪里？微信团队总结下来有三大难点：快——如何保证用户快速摇到红包？准——如何保证摇到的红包能成功拆开？稳——如何保证拆开的红包能分享出去？大量用户在同一时间摇红包，瞬间产生每秒千万级的请求，这个量级的请求如果不加以疏导处理直接到达后台，必定会导致后端服务过载甚至崩溃。上文中除夕当天后台监控数据曲线便能说明一切——在前台重重的分流减压下，后台服务器负载仍然瞬间飙升十倍以上。三大应对策略齐上阵对于以上三个难点，微信后台开发团队主要通过三大应对策略应对：有损服务，柔性可用，大系统小做有损服务-追求高可用和快速响应。什么是有损服务？有损服务是通过精心拆分产品流程，选择性牺牲一部分数据一致性和完整性从而保证核心功能绝大多数运行。这是腾讯在PC时代积累下来的一种特色运营策略——在资源一定的前提下，互联网条件千变万化的场景中，量力而为，满足用户的核心需求。微信红包的核心点是摇，拆，分享红包，整个系统设计时必须尽最大可能保证这三个步骤一气呵成，任何关联系统出现异常的时候马上进行系统降级，防止引起系统雪崩。系统降级可以分为两个方面，一是把核心功能进行分拆和简化，通过辅助轻量化的服务实现，确保最短关键路径的可行，比方说在接入层置入摇红包逻辑，将每秒千万级请求转化为每秒万级的红包请求，再传到红包服务的后端逻辑，降低雪崩的可能性。同时后端采用异步分拆，接收到用户请求时仅进行合法性验证，验证完成后直接告知成功，后续业务逻辑进入异步队列进行处理，减少了用户的等待时间，也极大降低了峰值雪崩的概率。耗时最长的入账操作，直接跳过，异步处理另外一方面是采取过载保护措施：微信红包的过载保护在客户端已提前预埋了策略，在连接失败或超时情况下会有相应提示，减少用户重复请求次数。接入层面也会进行自我保护，针对频繁发出请求的客户端限制响应速度，并对系统负载划分出若干等级，达到不同阈值时引导客户端使用不同限速速率；在异常情况出现时，采取减少红包数，异步限流降低拆/分享红包的速率等措施减轻服务器端压力；与此同时，微信红包还有全程压测流程，对整个业务链接进行自动提前评估，防止过载。这画面你可能没见过，它其实早已在手机待命在有损服务思想的重重保护下，第一波的摇红包体验活动中，微信红包几乎满分通过考验，其中过载保护的作用相当明显，在客户端、接入层层减压、过滤，最终仅把十万级压力传递到后台。柔性可用-细化场景把握核心需求。柔性可用是在有损服务价值观支持下的方法，重点在于实际上会结合用户使用场景，根据资源消耗，调整产品策略，设计几个级别不同的用户体验场景，保证尽可能成功返回关键数据，并正常接受请求，绝不轻易倒下。柔性服务更具有产品的思维性质，意义在于深刻理解产品每一个场景的核心价值，把握用户在每一个场景中的核心需求，设计不同层次的满足核心诉求的办法，对柔性服务在微信红包中的实践，红包团队也有相应的措施，主要可以分为几大类。1、系统容灾：面对大规模的请求量，系统容灾必不可少，容灾一般可分为逻辑层容灾和数据层容灾，这次微信后台开发团队在容灾布置中采用30%切换的逻辑层方案，即核心服务都能做到最多1/3服务器出问题的情况下自动容灾切换以保证服务质量，提高预警级别换取系统的可用性。2、资源隔离：顾名思义就是把资源进行隔离减少服务支路间的影响，从逻辑入手，在资源逻辑中，当A服务同时分派任务给BC服务时，设定单个最大分配上限值，避免任意一个支路出问题影响整个服务链条，这样即使部分服务出现问题也不会影响到整个服务的崩塌。3、快速拒绝：当服务过载时尽早拒绝请求，由服务调用方换机重试避免单一服务器重试过载，快速拒绝和有损服务中的及早拒绝是一个概念的方法，从过程的源头将问题解决，成本越低，影响越小，前端保护后端的方式来解决问题。4、支付分组：从支付环节入手，将所有红包分为50个组，放在50个单独的set上互不影响，单组set出问题最多只影响1/50用户，保证多数人服务不受干扰。分组set化也是柔性可用的一个重要技术手段，这一思维非常类似于现实生活中的集装箱思维——通过标准化，规模化的箱体设计，应对复杂多样的货物，使每个流通环节既独立又不失灵活。5、流量预加载：从客户端入手，将语音图片等极消耗流量的资源提前让客户端自动下载预置好，提前将流量洪峰疏导，并在活动当天CDN将准备数百G带宽应对，这块也与过载保护中的快慢分离是相通的，将耗流量的服务提前加载避免高峰期间的冲突。大系统小做-保证进程的功能单一 。大系统小做应该来说，是一种意识，他的核心思想是将功能复杂较大的系统，化大为小，减少模块耦合，降低关联性，用多个独立的模块来实现整体系统的功能，大系统小做采用的是化繁为简，分而治之，便于开发和迅速实现。微信红包如此庞大的后台系统，模块也相当之多，而这次的模块微信开发后台团队采用了系统高度模块化的方式，分成一个个高度自制的小系统，形成高内聚低耦合的格局，每个模块之间不会过分依赖对方，这样的好处是不会因为任何一个模块而影响全部服务，避免牵一发动全身的风险，实现真正的灰度服务。海量服务能力决定成败从2014的滴滴打车，到2015的微信红包，腾讯用一个个案例，去证明自身在海量服务方面的实力。事实上，真正支撑起微信红包顺畅运营的幕后英雄，正是腾讯内部一个叫做“海量之道2.0”的技术体系。有损服务，柔性服务，大系统小做三大手段也是脱胎于此体系中。移动互联网大战硝烟味愈浓，BAT都在为争夺支付入口使出浑身解数，在业务从起步到小跑再到腾飞的过程中，巨头背后的海量服务能力将对其最终成败有着来越发深远的影响。
转帖 原内容来自 微信公众号 Java那些事 如不妥即秒删突发奇想给校友微信群发了红包，我设定红包总额为10元，支持28个人随机领取于是一个有趣的结果出现了A 领取了 0.26元B 领取了 0.29元C 领取了 0.02元D 领取了 0.56元E 领取了 0.64元……微信是采用什么样的算法做到的？简单百度了下，目前尚未有官方的说明，仅仅在知乎里有一个较为热门的讨论，不过他们讨论的太过于深入，有掉坑之嫌。我按照自己的逻辑尝试了下，这个算法需要满足以下几点要求1、每个人都要能够领取到红包；2、每个人领取到的红包金额总和=总金额；3、每个人领取到的红包金额不等，但也不能差的太离谱，不然就没趣味；4、算法一定要简单，不然对不起腾讯这个招牌；正式编码之前，先搭建一个递进的模型来分析规律设定总金额为10元，有N个人随机领取：
则红包金额=X元；
为保证第二个红包可以正常发出，第一个红包金额=0.01至9.99之间的某个随机数
第二个红包=10-第一个红包金额；
红包1=0.01至0.98之间的某个随机数
红包2=0.01至(10-红包1-0.01)的某个随机数
红包3=10-红包1-红包2
至此，规律出现啦！开始编码！header("Content-Type: text/charset=utf-8");//输出不乱码，你懂的
$total=10;//红包总额
$num=8;// 分成8个红包，支持8人随机领取
$min=0.01;//每个人最少能收到0.01元
for ($i=1;$i&$$i++)
$safe_total=$total-($num-$i)*$//随机安全上限
$money=mt_rand($min*100,$safe_total*100)/100;
$total=$total-$
echo '第'.$i.'个红包：'.$money.' 元，余额：'.$total.' 元 &br/&';
echo '第'.$num.'个红包：'.$total.' 元，余额：0 元';
输入一看，波动太大，这数据太无趣了！第1个红包：7.48 元，余额：2.52 元
第2个红包：1.9 元，余额：0.62 元
第3个红包：0.49 元，余额：0.13 元
第4个红包：0.04 元，余额：0.09 元
第5个红包：0.03 元，余额：0.06 元
第6个红包：0.03 元，余额：0.03 元
第7个红包：0.01 元，余额：0.02 元
第8个红包：0.02 元，余额：0 元
改良一下，将平均值作为随机安全上限来控制波动差header("Content-Type: text/charset=utf-8");//输出不乱码，你懂的
$total=10;//红包总额
$num=8;// 分成8个红包，支持8人随机领取
$min=0.01;//每个人最少能收到0.01元
for ($i=1;$i&$$i++)
$safe_total=($total-($num-$i)*$min)/($num-$i);//随机安全上限
$money=mt_rand($min*100,$safe_total*100)/100;
$total=$total-$
echo '第'.$i.'个红包：'.$money.' 元，余额：'.$total.' 元 &br/&';
echo '第'.$num.'个红包：'.$total.' 元，余额：0 元';
输出结果见下图第1个红包：0.06 元，余额：9.94 元
第2个红包：1.55 元，余额：8.39 元
第3个红包：0.25 元，余额：8.14 元
第4个红包：0.98 元，余额：7.16 元
第5个红包：1.88 元，余额：5.28 元
第6个红包：1.92 元，余额：3.36 元
第7个红包：2.98 元，余额：0.38 元
第8个红包：0.38 元，余额：0 元
已有帐号？
无法登录？
社交帐号登录如果你有一台智能手机，如果你在上面装了某个软件，那么你今年的春节很可能是在下面这样的场景中度过的：这也使得众多的网友发出了下面的感慨：而最近几天不少群里面又流行起来一种“红包接力”的玩法，大概的规则是：群里面先由一人发一个红包，然后大家开始抢，其中金额最大的那个人继续发新一轮的红包，之后不断往复循环。这时候大家或许就会问了，一直这么玩下去会有什么结果呢？是“闷声赚大钱”了，还是“错过几个亿”了？是最终实现“共同富裕”了，还是变成“寡头垄断”了？要回答这些问题，我们不妨用统计模拟的方法来做一些随机实验，得到的结果或许会让你大跌眼镜呢。红包初级模型——切面条法要进行模拟实验，就需要设定一个红包金额的分配机制。但由于微信红包的算法并没有公开，所以我们只好从观察到的现象出发，“反推”出一个模型，让它尽量符合观察结果。其实这就是科学方法的精髓：我们也许永远不可能知道宇宙的“源代码”，但我们能为宇宙建立一个足够好用的模型。微信的红包是一个个抢的，所以很容易给人以这样的印象：红包一堆钱摆在那里，第一个人闭眼抓一把，第二个人再抓一把，等等。但是倘若果真如此，后来的人总体而言就要吃亏。这样既不公平，也不满足现实中的观察。所以，更合理的做法是，一开始就把所有的钱一次性分成几个包，每人抓一个，每个包都是等同的，里面的钱数期望都是总金额的几分之一。满足这个要求的做法当然不止一个，但我们先考虑最符合直觉的办法——切面条。假如你有一根面条要随机分成5根，怎么分？闭上眼睛剁4刀就行了。换成数学语言，就是在一条线段上随机扔4个点，分成5段。现在你要把红包分成5份，好办，拿出你刚才剁的面条，每一根面条有多长，对应的红包就塞多少钱。（当然，面条是连续的，而红包是离散的——每个包的钱数都是1分钱的整数倍。但钱多的时候这点差异无关紧要，而要是有人发了个全一分钱的红包，还是暂停讨论把他踢出群比较好。）以下就是切面条法分红包的一个实例，总金额为1元，分成5个：0.， 0.，0...这贫富差距也太大了吧？如果红包总金额是100，那么领得最多的人可以得到35.86元，而最少的只有2.67元。第一名得到三分之一多的钱，最后一名不到三十分之一？其实这完全不极端。对于这种分法，我们可以数学上证明，当1块钱（或者长度为1的面条）分成n份儿的时候，第k大的值，期望为1/n*(1/n+1/(n-1)+1/(n-2)+…+1/k)。（证明留作练习（被踢飞））所以，最大值的期望为 1/n*(1/n+1/(n-1)+1/(n-2)+…+1)，而最小值的期望为 1/n^2。换言之，在n=5的时候，平均而言，五个人应该分别拿到的红包大小是：0.456666……，0.256666……，0.156666……，0.09，0.04。真是朱门酒肉臭路有冻死骨啊。好吧，虽然这恐怕和很多人的印象相符，但毕竟也太悬殊了，能不能增加一个调节杆，让红包间的差异稍微小一点呢？红包进阶模型——狄利克雷分布复习一下刚才的切面条模型要点。1 一次可以生成n个随机数，且总和为1，这样每个数乘以红包总金额就是每个人分得的钱；2 每个随机数的期望应该均等，即n分之一，这是为了保证大家抢红包机会平等；现在我们为它增加一个第三条：3 有一个参数可以用来调节红包的“公平”程度。这里的公平不是指机会公平，而是说每次发红包大家实际拿到手的钱是不是相近，即金额分配的波动性是大还是小。比如100元的红包发给10个人，如果每人都是10元左右，我们认为这种分配更公平些；如果最少的才0.8元，最多的有20元，显然就有失公允了（不幸的是作者好几次碰到这种情况……）。幸运的是，在众多的随机变量分布中，有一个“狄利克雷分布”非常适合上面列出的这些情况。狄利克雷分布本身有n个参数，但为了满足条件2，我们可以只用一个参数 α 来决定它的具体形式。α 越大，每人分得的金额比例就越倾向于平均，反之则波动性越大。更幸运的是，我们开始提出的切面条分法，恰恰就是当α=1的时候，狄利克雷分布的最简单状态。（想深入了解狄利克雷分布，可以参考rickjin大侠的文章以及狄利克雷分布的维基页面。）刚才切面条的结果，也就是α=1时的狄利克雷分布生成的随机数0.， 0.，0...而下面是α=10时的一组随机数0.....1703169可以看出，当α=1时，金额分配的变动性非常大，而在α=10的情形下，金额的分配就平均多了。模拟接力游戏，开始有了这个假想的红包分配机制，我们就可以来模拟红包接力的游戏。首先假设我们有一个50人的群，每人初始手头上的可用金额为50元（这里是为了产生“破产”现象而故意放低的，土豪们请忽略此设定），根据规则，每次红包的总金额是20元，发放给10个人，其中抢得最大红包金额的人将发出下一轮的红包。如果某人发完红包后余额变成了负值，就不能再继续抢红包（请原谅这个丧心病狂的设定……），因为他/她已经发不起下轮红包了，但允许现在其余额为负。在我们的模拟中，依然对实际情况做了很多简化，比如假设抢到红包的人是在参与游戏的人中间均匀分布的（排除了资产为负的人）。在实际情况中，大家可能会根据自己余额的多少来决定是否继续参加，但在此我们忽略了这种可能。我们设定 α=2，并让红包接力100次，最后大家的余额如下：31.24 & &82.69 & &18.07 & &44.56 & &62.87 & &33.40 & &47.00 & &45.55 & &77.11 & &70.4454.28 & &26.98 & &54.74 & &80.30 & &28.32 & &43.98 & &48.80 & &82.69 & &82.94 & &-11.0034.30 & &80.64 & &60.68 & &47.34 & &40.13 & &52.55 & &23.39 & &62.67 & &92.20 & &72.4341.55 & &40.12 & &50.51 & &81.30 & &51.17 & &43.36 & &34.93 & &64.38 & &42.70 & &-8.909.10 & &78.61 & &46.35 & &64.18 & &61.90 & &13.61 & &50.01 & &68.51 & &41.21 & &54.14可以看出，有两位朋友不幸破产了，而最后资产最多的有92.20元，几乎翻了一倍。一个很明显的事实是，破产的玩家都是因为“中头奖”中得太多了， 导致入不敷出。相反，最终收得92.20元的这位玩家属于“闷声发大财”。经统计，他/她获得第一名0次，第二名3次，第三名2次，第四名2次，第五名4次，等等。下面这个flash展示了每个人的金钱变动状况：（看不到的请用微信扫一扫）当然，概率面前人人平等，没有谁能预知自己抽中红包后会是最大的还是最小的，所以从对称性的角度考虑，个人选择的结果是完全随机的。但是，从整个群的角度来看，有一个指标却在悄悄发生变化，那就是这个群的“贫富差距”。平均还是独大？基尼系数来判断我们注意到，在游戏最开始的时候，大家的资金都是一样的（50元），而在100次接力之后，几家欢喜几家愁，贫富差距被拉大了。于是我们有两个很自然的问题：1. 如何量化这种贫富差距？2. 随着游戏的进程，贫富差距会有怎样的变化？对于第一个问题，我们可以借用经济学中的一个概念来予以回答，那就是所谓的“基尼系数”（Gini Coefficient）。基尼系数通常被用来衡量一个国家居民收入的公平性，其取值在0到1之间，越大表示贫富差距越大，即少部分的人掌握了这个经济体大部分的收入。基尼系数的计算公式可以在它的维基页面中找到，对于之前的模拟游戏结果，计算出的基尼系数是0.2551。这个结果的绝对数值可能并没有太大的意义，因此我们在每一轮接力之后都计算出当时这个群的基尼系数，然后观察它的变化。结果如下：在这里我们将接力次数延长到了500次。可以看出，随着接力的进行，基尼系数的整体趋势是在不断变大的，意味着贫富差距会随着游戏的进行变得越大。这其实很好理解：总是会有人因为拿了太多头奖而破产，这样财富会在越来越少的人中间进行分配，所以相应地贫富差距就拉大了。红包越“公平”，贫富差越大前面提到，在我们的模型中有一个参数 α 用来控制红包金额分配的“公平”程度（或者更准确地说，是“平均”的程度，因为就机会而言，每个人分得金额的可能性都是相同的，但就每一次实际分得的金额而言，α 越大，这种分配越倾向于平均，即结果的波动性越小）。下图展示了一组随机模拟实验的结果，其中我们模拟了20次红包接力的游戏，10次取 α=2， 另外10次取 α=20。每次游戏中，红包都接力了500次。可以看出，红线和蓝线虽然有所重叠，但总体来看蓝线的取值要比红线更大，也就是说，红包金额越“公平”，贫富差距反而会越大。这个结论看起来可能有些反直觉，但其实也合情合理：如果红包的分配是绝对公平的，那么第一名得到的金额就将是2元，而下一轮又必须送出20元，所以 总共亏损18元；如果红包金额的波动性很大，就会有一部分人得到的金额小于2元，而第一名就会得到更多，也就更不容易破产。所以说，一个规则是否真的“公平”，不能只看其表面。出人意料的更多玩法除了前面提到的这个规则，我们还可以考虑一系列其他的玩法：1. & &之前的规则记为1号；2. & &玩法2：第一个红包金额为20，第二个为21， 第三个为22，……到30后又递减至20，以此反复；3. & &玩法3：下一个红包的总金额是上一轮的最大金额加10；4. & &玩法4：下一个红包的总金额是上一轮最大金额的4倍，30封顶；5. & &玩法5：下一个红包的总金额是上一轮最大金额的5倍，30封顶；你一定奇怪玩法4和玩法5只差一个数，为什么要单独列出来。这里可以先剧透一下，原因是它们有着天壤之别。在给出结果之前，大家可以先根据自己的直觉给这几种玩法排个序，然后再和下面的结果对比一下，看看是否真的让你大跌眼镜了。321下面是这五种玩法的对比图，全部取10个红包，α=2，初始20元。每种玩法我们模拟10次，也就是有10条基尼系数曲线。可以看出，按照贫富差距排序，从大到小分别是玩法5&玩法2&玩法1&玩法3&玩法4。怎么样，你猜对了吗？我相信你一定被4和5之间的“天壤之别”惊呆了。为什么一个是最大，而另一个甚至是平坦的呢？其实，规则里面4和5这两个系数非常关键。在α=2丶分10个包的条件下，第一名平均能拿到红包金额的23%左右。4乘以23%得到0.92&1，换言之红包会变得越来越小。比如第一轮最大如果是4，下一轮的总金额就是16；这一轮最大可能就变成了3，那么再下一轮总金额就变成了12……到了后来，总金额小于1分钱，就保持不变了（图中的水平线部分）。相比之下，5乘以23%得到115%，结果红包会变得越来越大，而由于我们设定了30块钱封顶，会让每个红包稳定在30元附近，因此贫富差距就按照“正常”的趋势逐渐加大了。可以想见的是，在4倍和5倍之间应该会有一个临界值，把这两种极端情形分隔开来。时间所限我们没有进行严谨的理论推演，但随机模拟表明这个数字在4.35左右。最后的话正如开篇所言，这只是红包算法的一个模型，并不一定就是背后的真实源代码。从经验和直觉上来看，这个模型（特别是在α较小时）对现实的模拟还算令人满意，不过严格的科学方法当然要做统计分析来验证这一模型是否符合现实了——鉴于验证繁琐，红包数据收集不易，而且本身就是个娱乐项目，此处就不再对此较真。欢迎感兴趣的读者进行更深入的验证。除了本文考察的这些可能影响金额分配的因素之外，读者还可以利用文中用到的代码继续考察其他因素对贫富差距的影响（可能需要对代码稍作修改），比如红包人数，初始金额等等。最后提醒大家的是，红包主要还是在过年的时候图个喜庆，游戏有风险，抢包需谨慎。本文原载于统计之都
@你关注的人或派友
亲，先登录哦！
【线下加油站】
圈子·资源·联合·互换
赢战双11，店铺全年高效盈利实训
10月15日-10月18日 （北京站·4天4夜）
10月20日-10月23日 （广州站·4天4夜）
电商服务商o【优选】
运维神器，全网惠战！
十年沉淀成就电商ERP用户数第一！
品牌换装首选e盒印99大促！
请输入姓名：
请输入对方邮件地址：
您的反馈对我们至关重要！