简介：面向微信生态运营者与PHP二次开发人员，这套H5幸运刮刮乐抽奖系统提供免公众号直运营的多级分佣方案，内置后台管理与支付接入框架，适合快速落地抽奖活动或扩展分销玩法。资源共2013个文件，压缩包仅33.83MB，主要包含PHP后端逻辑、JSON配置数据、JavaScript交互脚本、PNG/GIF图片素材以及Markdown说明文档，体积精简且结构相对清晰。目前已有180人学习下载，可作为同类项目的参考实现。源码可直接上传部署，适配MySQL5.6与PHP7.2环境，需完成Swoole、redis等扩展配置；后台默认账号便于快速登录，可修改数据库连接、公众号APP ID、回调地址与支付商户参数，为后续微信内正常访问和支付流程对接留有明确改动位置。整体适合作为H5抽奖系统的快速搭建模板，也适合需要了解刮刮乐实现、多级分佣逻辑的开发者参考。 “H5幸运刮刮乐抽奖”这半年越来越多人在搜，尤其是“免公众号+直运营+多级分佣”这几个词组合在一起的需求特别典型。我实际调研和拆解过好几套这类系统，从产品设计、技术实现到分佣机制，每个环节都有不少门道。这篇文章就把我看到的、验证过的东西完整梳理一遍，给想自建或者评估这类系统的朋友一个参考。
1. 刮刮乐H5的定位：为什么“免公众号+直运营”是刚需
先说我这半年观察到的现象。传统H5抽奖活动大多数长在微信公众号生态里，需要服务号、需要网页授权、需要用户先关注才能参与。这一套流程对于有大把预算、有专门运营团队的大品牌来说没什么问题，但对中小商家、个人创业者和做私域流量的人来说，门槛是很高的。我见过不少案例，活动本身设计得挺好，结果卡在公众号认证、域名校验这一步，白白错过了推广周期。
“免公众号”解决的就是这个核心痛点。用户拿到链接或二维码，手机浏览器直接打开就能玩，不需要跳转微信授权页，不需要关注公众号，更不需要下载App。这个“直连”能力释放出来的价值非常大，尤其是在投放场景里——你可以把活动链接直接挂在抖音、快手、朋友圈广告、短信营销、甚至线下物料上，用户点击即玩，转化路径短到极致。
“直运营”则是另一层诉求。很多第三方抽奖平台确实提供类似功能，但你仔细看协议就会发现，数据不在你手里、规则受平台限制、用户画像沉淀不到自己池子里。直运营意味着整个系统部署在你自己的服务器上，用户数据、活动数据、分佣数据全部自己掌控，想怎么玩怎么玩，想改规则随时改，不依赖任何中间平台。
这整套需求的本质，是流量获取成本越来越高之后，大家开始追求“一人一链接、一场一活动”的独立运营模式。刮刮乐这种玩法本身自带强互动性和即时反馈的爽感，配合免公众号的轻量触达和多级分佣的裂变激励，天然适合做拉新、促活、品牌曝光、老带新传播。
从技术角度看，这套系统通常包含三块：H5刮刮乐前端（用户交互部分）、免登录授权与用户身份识别层、多级分佣与结算后台。我拆过几套开源的和商业的版本，整体架构大同小异，但细节差距很大，下面逐个说。
2. 刮刮乐玩法的产品细节：奖面设计、中奖率控制与参与动线
很多人以为刮刮乐就是把一张图片贴上去，涂层刮开显示结果就完事了。实际做产品设计时，真正影响活动成败的反而是一些看不见的规则和参数。
2.1 刮刮乐交互的三种形式与选型
市面上的H5刮刮乐，交互上大致分三种：canvas刮涂层、像素级蒙层模拟、纯按钮揭开。
canvas刮涂层是最常见也是最靠谱的做法。用canvas绘制一层覆盖物，监听touchmove事件，通过globalCompositeOperation = 'destination-out'把手指划过区域的像素擦除。判断“是否刮开足够比例”时，可以定期读取canvas的像素数据，计算透明像素占比，达到阈值比如60%就自动揭开结果。我实测下来，这种方式在iOS和Android的浏览器里兼容性都很好，而且视觉效果最接近真实刮刮乐。
像素级蒙层模拟是用多个小div格子组成蒙层，手指划过时把对应格子隐藏，这种方式在低端安卓机上反而更流畅（因为不涉及canvas像素级操作），但视觉效果颗粒感重，刮开边界不圆滑，体验差很多，只建议在必须兼容超低端设备的场景下用。
纯按钮揭开就是“点击刮开”按钮直接显示结果，这个基本没有“刮”的爽感，互动性大打折扣，不太推荐作为刮刮乐的核心玩法，顶多作为无障碍访问的备选方案。
2.2 中奖率设计：不是拍脑袋定的事
中奖率是整个活动的灵魂，直接关系到预算和用户满意度，一定要用倒推法来算。我拿一个实际验证过的案例来说明。
假设活动预算一共1万元，计划发5000份奖品，其中一等奖1名（价值3000元手机）、二等奖10名（价值200元礼品）、三等奖100名（价值50元礼品）、四等奖4889名（价值2元的现金红包或优惠券）。那么总中奖率就是5000/10000=50%，算下来所有用户里有5000人能中奖。这种看似简单的计算，实操中有几个坑要特别注意：
- 奖品实际价值 vs 标价：分佣模式里经常有“奖品虚高”的玩法，比如标价299元的大礼包，实际成本30元。这个在合规运营场景要谨慎，如果是真实自有商品清库存那没问题，但纯虚标会伤用户信任。
- 中奖率可以动态调整：高级一点的系统支持“保底中奖”和“时段中奖率”。我见过做得比较精细的做法，是前100名参与的必中小额红包（用于社交传播），中间时段中奖率压低（控制成本），最后时段再拉高（保证整体活动预算花完）。
- 限玩次数设计：每人每天只能玩1次还是3次，直接决定奖池消耗速度。常见做法是“基础1次+分享好友再得1次+抽奖消耗积分可兑换额外次数”，既控制成本又给了裂变动力。
2.3 参与动线：少一步，转化可能差一倍
动线设计的原则是能一步走完绝不两步。用户打开链接看到的第一屏就要能直接开刮，不要先弹登录框、不要先让你填手机号、不要先弹关注公众号。这些都可以放在“刮完看到中奖结果”那个节点再引导。
我之前看到一个案例，同样的活动和奖品，加了登录步骤后参与率掉了超过一半。用户拿到一个链接，点开还要注册/登录/授权，耐心会迅速耗尽。刮完奖再引导“登录领奖”，这个节点用户有明确的行动动机，转化率反而很高。这是免公众号模式天然的优势——把原来前置的授权挪到后置，把“门槛”变成“激励”。
2.4 前端性能：低端机才是试金石
这个项目的H5页面主要依赖CSS3动画和Canvas交互，如果并发量上来（尤其是配合分佣裂变传播），页面加载速度和运行流畅度直接决定用户会不会玩到第二遍。我强烈建议首页只保留首屏交互所需的图片和脚本，把奖品列表、规则说明、分佣中心这些做成懒加载；领奖页面单独做路由，别把所有资源一次性塞进来。还有一层容易被忽略的是图片体积，一张背景大图几MB是常事，务必用WebP压缩到几百KB以内。实测低端安卓机上，同样的游戏逻辑，图片优化前后首屏加载从8秒降到2秒以内。
注意：canvas刮涂层的实现建议用“局部重绘”优化，不用整张画布频繁重绘。核心逻辑是每次移动只清除手指附近的小区域，帧率能提升一个档次，老手机上也能保持流畅。
3. 免公众号的技术实现：身份识别与数据贯通的三种路径
这是整个系统最关键、也最容易让人迷惑的部分。免公众号不代表不要用户身份，而是要用别的方式识别用户。
3.1 路径一：纯游客模式（设备指纹+本地存储）
最简单直接的做法。用户第一次打开时生成一个UUID存在localStorage里，后续所有行为（刮奖、中奖、绑定推荐关系）都基于这个UUID。
优点是实现最快、没有授权弹窗、体验最顺。缺点也很明显：用户清缓存或换设备，身份就丢了，领奖时可能找不到记录。这个方案适合“低客单价、一次性活动、用户不换设备”的场景，比如门店扫码即玩即领小礼品。
3.2 路径二：手机号验证码辅助绑定
用户中奖或提现时输入手机号，系统把游客观众身份和手机号绑定。相当于把身份从“设备级别”提升到“人级别”。
这个方案是我个人最推荐的折中方案——它不打扰用户的前期参与动线（不需要一进来就输手机号），又能在关键节点（中奖、提现）拿到真实联系方式，为后续二次触达留了口子。手机号验证可以接阿里云/腾讯云的短信服务，成本大约每条几分钱。
配合这个方案，还可以顺带做一个小功能：输入手机号后，如果数据库中已存在该手机号的历史中奖记录，就自动合并到当前身份下。这能避免用户换个设备就提不了现的情况。
3.3 路径三：飞书/企微/钉钉等内部工具的免登授权
为什么要提这个？我搜热点词的时候注意到“飞书H5免登录授权”是个高频搜索。这说明这类架构被大量用在了企业内部的运营场景——员工在企业聊天工具里打开活动页，希望自动带上企业身份，而不是又弹出一个独立登录框。
这个的实现原理其实和微信网页授权一样，走OAuth2.0：H5页面跳转到飞书/企微的授权链接，用户确认后回调带上授权码，后端换取用户身份信息。区别在于：企业自建应用钩子配置在应用后台，比公众号少了“服务号认证”这一层硬门槛，所以很多中小企业反而能更快落地。
只要H5页面是纯前端渲染，这个免登逻辑可以完全复用。建议把授权逻辑封装成一个独立的函数，在入口路由里统一判断、统一回调，避免“页面A要登录、页面B不用登录”这种混乱状态。
3.4 身份识别与数据贯通的注意点
做免登录身份体系，有几个问题一定要提前想清楚，不然后期会非常痛苦：
- 并发重复注册：如果用户同时打开多个页面，可能生成多个UUID。建议用“首次访问即生成+全局单例”的方式，确保同一浏览器会话内身份唯一。
- 多端同步：同一个用户手机、Pad、电脑上各有一个UUID，数据完全割裂。手机号绑定可以部分解决，但做不到实时同步。
- 数据埋点：从第一步就要把来源渠道、落地页、推荐码这些参数完整记录下来。没有渠道数据的裂变活动等于瞎做，后面连调整方向都无从下手。
4. 多级分佣系统的规则设计：防刷、结算与合规运营的边界
标题里的“多级分佣”是整个系统的核心商业引擎，也是争议和风险最大的地方。做之前一定要把规则设计清楚，同时明确几个法律和平台的硬边界。
4.1 合理层级与分销逻辑设计：两级以内最稳妥
从业务角度，我建议把分佣层级控制在两级以内（用户A直接邀请的用户B，以及B再邀请的用户C）。这既保留裂变的传播动力，又大幅降低规则被判定为违规传销的风险。具体规则可以这样设计：
- 一级分佣：用户A直接邀请的用户B参与活动并中奖/消费，A获得对应佣金的30%-50%；
- 二级分佣：B再邀请的用户C参与活动并中奖/消费，A获得对应佣金的10%-20%；
- 结算条件：可以是“C中奖即触发”，也可以是“C完成提现才触发”。后者更保守，能避免“发了没提现”造成的手续费损失，但用户感知弱一些。
还要设计“三级保护机制”：被邀请用户30天内重复参与活动，邀请者只能获得固定比例的奖励封顶，避免恶意重复刷邀请链接。
4.2 防刷机制：这是一个技术系统最见功夫的地方
任何带现金/实物奖励的分佣系统，都会被羊毛党盯上。我拆过几套系统，发现防刷机制做得越好，长期运营越省心。至少要有这五道防线：
- IP维度限制：同一IP每天最多注册N个新用户，最多参与M次活动；
- 设备维度限制：通过浏览器指纹识别，同一设备最多绑定N个身份；
- 行为维度监测：参与时长异常短（<3秒就完成刮奖）、中奖频率异常高、邀请关系建立异常快，都需要触发人工或自动风控；
- 手机号维度：同一手机号在活动期间只能绑定一个身份；
- 黑产库比对：有条件的可以接入专业的风控API，识别被标记的设备和手机号段。
这里多说一句，分佣系统最怕的不是用户薅奖品，而是被薅到系统崩溃、被薅到预算超标。所以每一层都要有实时的阈值控制和预警，超限自动触发暂停和人工审核。这个我也有个经验：一开始把阈值设紧一些没关系，运营跑顺了再逐步放宽，比一开始什么都没踩住被刷爆了之后再补救靠谱得多。
4.3 结算与提现流程设计
分佣金额通常不大，提现流程要做得轻。我见过两种主流做法：
一种是微信/支付宝转账到余额，用户可提现到零钱/银行卡。另一种是直接发积分/优惠券，在自有商城抵扣。前者体验好但涉及资金托管、结算手续费，后者零成本但用户感知弱。
非技术层面的关键问题是提现门槛不能太高。佣金满1元即可提现，比满50元才能提现的激励效果强得多。设置过高的门槛等于告诉下面的推广者“你们白干了”，裂变意愿会瞬间衰减。另外每次提现的手续费由平台承担还是用户承担，要在活动规则里说清楚，避免纠纷。
4.4 合规运营的硬边界
这一部分我必须明确讲清楚。分佣系统天然游走在灰色地带，但作为实际运营者，有几个硬底线绝对不能碰：
- 不以“拉人头”为核心计酬：严禁把收益直接跟发展下线人数挂钩，不能按人头计费。合规的做法是：收益必须跟实际商品销售或实际中奖消费金额挂钩。
- 明确拒绝多级返利：超过三级的分销返利，在国内法律环境下极大概率被认定为传销。即使是两级，也要确保每笔佣金来源是实际的商品交易或服务消费，而不是纯资金盘流动。
- 用户同意与公示：邀请关系要在用户协议里写清楚，被邀请的用户要能明确知晓“通过谁来的”，最好在授权绑定时二次确认。
- 税务问题：推广者获得佣金达到一定金额，需要做代扣代缴或要求对方提供对应发票。这个在实际运营中容易被忽略，但一旦规模做大，是绕不开的合规环节。
如果活动带有明显的资金盘属性、纯靠拉人头赚钱、没有真实商品服务托底，这套系统无论如何美化，本质上都等同于违规运营。我见过一些自称“三三裂变”“多级分佣”的项目，底层就是资金盘，那种东西建议直接放弃，做与不做是性质问题，不是技术问题。
5. 服务器部署与数据安全：直运营模式最容易忽略的后半场
直运营听着爽，但也意味着运维责任全在自己身上。很多非技术背景的运营者拿到代码部署上线就觉得完事了，直到被攻击、数据泄露、活动崩溃才意识到问题的严重性。
5.1 服务器选型与配置建议
对于一场预期并发几千至几万的活动，我建议的起步配置是这样的：
- 云服务器：2核4G起步（阿里云/腾讯云的最低配活动机基本够用），带宽按实际流量预估，5Mbps到10Mbps；
- 数据库和Web服务：如果并发预期不高可以同机部署，预期高分开部署；
- CDN：静态资源（前端JS、CSS、图片）务必走CDN，大幅降低服务器压力；
- 对象存储：中奖奖品图片、用户上传内容不要存服务器本地，用云存储服务。
数据库方面，活动量级其实MySQL就够用，如果你是Node.js技术栈，MongoDB也能胜任。关键是把数据库索引建好——用户表、邀请关系表、活动记录表、分佣记录表，这几张表关联查询非常频繁。
5.2 接口安全与防刷
接口层面最基础也最重要的是防并发请求：用户连续点击“刮奖”按钮，后端要能识别重复请求，做幂等处理。前端按钮置灰只是引导，真正的防御在后端。
其次是前后端分离后的跨域配置，只允许自己域名的请求访问API，防止别人直接拿你的接口去刷。推荐加一层简单的Token机制：用户首次进入H5时，后端下发一个临时Token，后续所有接口携带这个Token。免费模式不需要做太重的登录态，但基础鉴权不能省。
5.3 数据备份与防泄露
直运营意味着用户手机号、邀请关系、提现记录、分佣数据全在自己库里，一旦泄露不仅是声誉问题，还涉及法律问题。所以：
- 数据库一定要开启自动备份（至少每天一次）；
- 运营后台、API接口必须全程HTTPS加密传输；
- 敏感字段（手机号、身份证、提现渠道信息）加密存储，不要明文入库；
- 权限管理只给真正需要的人看数据，分佣明细、用户明细尽量按权限区分查看范围。
提示：这类系统最容易出安全事故的位置通常不在正式业务接口，而是运营后台的弱密码、未鉴权的导出接口，以及第三方短信/邮件服务商的key泄漏。上线的第一件事就是改掉默认密码，并把敏感接口全链路过一遍鉴权。
6. 前端适配与体验优化：微信内置浏览器、iOS Safari和安卓的坑
这个项目在微信、飞书、钉钉、普通浏览器里都会被打开，前端适配的工作量比想象中大得多。我在调研相关热搜词时注意到好几个高频痛点恰好都是这套系统最容易踩的坑。
6.1 微信内置浏览器无法隐藏的返回条
热搜词里有人问“微信打开H5怎么强制去掉自带的那个返回条”。结论很明确：微信内置浏览器顶部自带的导航栏和返回按钮，从技术层面无法完全去掉，这是微信为了用户安全和体验做的强制设计。想做“沉浸式”效果的，最接近的方案是用微信的“全屏模式”（需要服务号且配置JS-SDK），但在免公众号的模式下这条路走不通。
实际处理方式就是把页面设计得“矮”一点——不要用100vh高度硬撑满屏，用动态视口单位viewport height，让页面内容和微信导航栏共存时依然布局自然。最稳妥的方案是设计时就默认有导航栏占位，底部留出安全区，别让关键按钮被遮挡或需要额外滚动才能点到。
6.2 iOS Safari输入框自动上顶问题
这也是热搜里反复出现的问题：iOS Safari中H5页面输入手机号时，键盘弹起页面会自动上顶，设置了adjust-position也没用。这个问题根源在于iOS输入框聚焦时的手势行为和键盘的resize事件触发的滚动高度改变。
业界比较高效的解法是监听window的resize事件，在输入框聚焦时主动把页面滚动位置重置到可视区域顶部，输入框失焦后再恢复。另一个更稳的方案是把输入弹层改成iOS的原生弹窗（prompt），或者在布局上让输入框永远保持在视口安全区域内，不随键盘弹起而被挤到上面。这个调试起来比较费神，建议拿真机测试，模拟器上iOS Safari的行为不够真实。
6.3 微信内置浏览器H5视频/音频默认静音
如果活动里放了“中奖播报”音效或奖品展示短视频，微信内置浏览器默认是静音启动的。这个问题在H5直播间场景特别突出，很多人问“如何开声起播”。这背后是微信对自动播放的严格限制：浏览器会默认拒绝带声音的媒体自动播放。
所以活动页的音频/视频元素，要么做成静音自动播放，由用户点按一次后开启声音；要么在触摸事件（touchstart/click）里手动调用play()方法并赋予声音。最稳妥的做法是把“有声模式”设计成用户主动点击“开启声音”按钮后才激活，以此为触发点去开启所有音频播放。强制自动播放带声音内容不仅可能被浏览器拦截，还非常影响体验，不建议硬搞。
6.4 低端安卓机的Canvas性能优化
刮刮乐依赖Canvas画布，低端安卓机在连续TouchMove时会明显卡顿。排查方向不外乎几个：把Canvas尺寸按设备像素比（DPR）控制在合理范围内，避免超高分辨率的全屏画布；刮涂层绘制时使用局部重绘而不是整幅画布重绘；刮开检测不要每一帧都做全图像素分析，降低采样频率比如500ms分析一次，或只分析部分关键像素点。
还有一个细节容易被忽视：Canvas在页面滚动或路由切换后，画布内容可能被浏览器回收。务必在页面可见性变化（visibilitychange）和路由生命周期里保存绘制状态，否则用户辛苦刮到一半涂层就消失了。
6.5 使用Vue/UniApp开发时的工程化细节
如果这套系统用Vue 3（或uni-app）开发，组件和资源加载顺序要好好设计。刮刮乐页面做成独立路由，路由级懒加载，避免主包过大。不推荐把所有功能都写进一个页面里处理，否则首屏脚本体积会非常大，影响打开速度。
音频、图片等静态资源一律走CDN，并且要配合文件名指纹（带hash的版本号），这样每次更新活动配置后CDN不会给用户旧资源。活动配置数据（奖品池、中奖率、活动时间）建议独立成一个JSON接口，不要写死在前端代码里。好处是运营人员自己就能改活动参数，不用每次发版。
7. 真实运营中的成本测算与效果评估
活动做完上线只是开始，真正考验的是算账能力。一个看似划算的抽奖活动，实际运营后亏到肉里的案例我见过太多了。
7.1 成本的完整构成
一场刮刮乐活动的总成本必须把下面这些全部算进去，缺一样都可能超支：
- 奖品成本：中奖率设计时决定这个数，按最终实际中奖数量结算；
- 平台基础成本：服务器/带宽/CDN/短信服务，按月或按量付费；
- 分佣成本：所有推广者拿走的佣金总和；
- 提现手续费：给用户提现时第三方支付平台的手续费；
- 风控与客服成本：被投诉、纠纷处理、人工审核的人力投入。
举个例子：活动预算2万，奖品花了8000，分佣发了7000，平台成本3000，手续费+其他2000，加起来刚好持平。但如果中奖率设计失误，奖品成本冲到12000，整个盘子就亏了。
7.2 关键指标怎么看
直运营模式最大的优势就是数据全在自己手里，不把这些指标分析到透，等于资源浪费：
- 活动参与率：打开H5的用户里，多少人真正完成了刮奖动作；
- 分享率：参与用户里，多少人主动分享出去触发了裂变；
- 转化率：从分享点击到新人参与的转化，直接衡量你的邀请奖励是否有吸引力；
- 拉新成本：总预算除以新增的有效参与者数量；
- 分佣成本占比：如果分佣成本占总预算比例过高，说明激励结构存在问题或者佣金标定脱离实际。
我之前见过的一个案例，某团队把主要奖品设置成自家滞销库存，中奖率却给得很高（60%以上），导致中奖用户满意度极高，但分佣比例设计得偏低，推广者积极性不足，活动传播速度慢，最终效果平平。后来把佣金从抽奖奖金里单独拿出一部分，且改成“邀请用户完成首次刮奖就即时结算”，分享率立刻涨了接近一倍。激励的及时性和确定性，比单纯提高奖金额度更有用。
7.3 活动结束后怎么办
一次性的刮刮乐活动做完了，用户沉淀下来了，才有最大的价值。建议务必在活动中就把“关注公众号引私域”或“加入企业微信群”作为兑奖的前置引导。兑奖本身就是一个天然的加粉理由，不用白不用。活动结束后，积累的用户手机号、OpenID、邀请关系，才是真正留下来的长期资产。下一轮新活动上线时，给老用户发个专属链接和复购券，比从零开始拉新划算得多。
8. 我踩过的几个坑和最后的建议
最后说几个实操中印象最深的教训，给动手做这个项目的朋友一些直接的参考。
第一个坑是中奖率配置错了没有预警机制。我见过一个活动上线当晚，因为把“中奖率50%”误配成“5%”，用户大面积不中奖，口碑一夜崩塌。从那以后我给自己定的规矩是：不管后台能不能动态改配置，都必须有一个“活动数据异常自动熔断”的机制——比如单小时中奖人数超过预设值，自动暂停发奖并通知管理员。
第二个坑是对短信渠道依赖过重。很多活动把“登录领奖”设计成必须收到短信验证码才能兑奖。结果高峰期短信服务商审核或通道拥堵，验证码发不出去或延迟几分钟才到，用户体验极差。后来改成“手机号绑定优先，验证码作为第二道保障”，这个问题才缓解了不少。
第三个坑是Canvas在微信内置浏览器的离屏渲染问题。我们曾经遇到过部分用户反馈“刮完了一片还是显示不了中奖结果”，排查了很久发现是Canvas绘制区域在部分安卓机型上被浏览器裁切了。解决方案是给Canvas设置固定尺寸而不是撑满全屏，而且绘制前用getBoundingClientRect拿真实坐标，不能用window.innerHeight去猜。
第四个坑是不要一上来就做三级分销。前文讲合规时提到过两级以内更稳妥。除了法律风险，三级分佣的结算复杂度、黑产关注度、客服咨询压力都会成倍上升。跑通一级、二级的模型，验证了单位经济模型能转正，再考虑扩展，这是更理性的路径。
最后，做这类项目一定要有一个朴素的判断标准：用户拿到奖品时的感受，是否跟他付出的行动成本匹配。刮刮乐的爽感来自“刮”这个动作本身和即时揭晓的悬念，如果奖品太弱、门槛太高、流程太长，这个爽感就没了，任何花哨的分佣设计都救不回来。先把基础体验做好，再谈裂变和分佣，顺序不能反。
本文还有配套的精品资源，点击获取
