简介：一套基于ASP+MySQL的BingSNS多社群平台系统源码，定位为社群、商城、直播、分销一体化的社交电商平台，适合需要搭建私域社群裂变体系的开发人员或运营团队。系统以群规等级为骨架，覆盖建群数量、人数上限、群收款、付费提问、商品分销、备货供货等权限控制；同时集成群直播、聊天室、二级推荐分佣、实时提现等功能，并支持平台自定义装修与PC端热帖静态化，从运营玩法到交易闭环都比较完整。资源包共1700个文件，以gif、png图片和asp脚本为主，辅以js、css、html等前端文件及少量数据库文件，压缩包大小8.35MB。源码附带搭建流程说明，重点展示了Inc.asp配置文件、微信公众账号接入及直播推流地址设置，便于本地部署和二次开发。该资源已有204人学习下载，适合希望参考完整社群分销系统架构、研究层级佣金计算或改造直播互动场景的读者。
1. BingSNS多社群平台系统拆解：社群、商城、直播、分销的耦合设计
拿到这套 BingSNS 源码第一眼会以为是传统 SNS 社区，实际跑起来才发现它把群等级做成了权限引擎——建群数量、群费扣点、直播绑定、分销层级全部绑定在群规等级上。也就是说，不是让运营者手工给每个群开权限，而是用户靠推广人数、消费额、直接缴费三件事升级自己的群权限，这套设计在 2010 年代为数不多，放到现在做垂直社群电商依然有参考价值。系统基于 ASP 经典模式 + MySQL，后端用 VS2010 维护，前端是 PC 为主，但聊天室和直播都预留了手机端接口。适合正在做社群裂变、内容付费、多级分销产品的团队拆解，尤其是想理解“等级即权限”和“商品供应价分佣”怎么落地的人。
2. 系统架构与权限模型：从 Inc.asp 到群规等级
2.1 源码结构与入口文件职责
解压BingSNSMultiCommunityPlatform.rar后，主目录下的 ASP 文件数量不多，但每个文件承担了关键角色。我习惯先按入口文件、类文件、模板文件三类划分：
| 文件 | 职责 | 备注 |
|---|---|---|
merge.ashx | 通用异步处理入口 | 处理前端 AJAX 请求，如点赞、关注、聊天室消息 |
inc.asp | 全局配置包含文件 | 数据库连接、站点域名、微信 Token、直播源地址 |
Main.asp | 主逻辑控制器 | 根据action参数路由到不同业务模块 |
Class_Main.asp | 核心类库 | 封装用户、群组、订单、佣金计算等对象 |
Index.js.asp | 首页动态 JS 输出 | 以 ASP 输出 JavaScript，动态生成页面部分数据 |
Index.asp | 首页入口 | 负责加载首页框架及静态化内容 |
Wangpu.zzs.dh.asp | 网铺导航页 | 群铺、商品铺、分销铺的展示 |
Wangpu.zzs.asp | 网铺主页面 | 商品列表、供应价、佣金比例展示 |
Sns.Group.Show.asp | 群详情页 | 群聊、群贴、群商品、群成员管理 |
注意a_Inc/Inc.asp是配置文件，搭建时第一件事就是改这个文件。里面Cls_Rtmp和Cls_M3U8不是普通的 RTMP 播放地址，而是直播拉流地址，后面第 3 章会详细讲。
2.1.1 入口文件的路由逻辑
Main.asp是典型的“单入口 + action 参数”模式。类似地，Index.asp也会根据mod参数决定输出首页的哪个板块。看源码时抓住Request("action")或Request("mod")的取值，就能梳理出全部功能点。
2.2 群规等级的三维升级机制
群规等级是整个平台的权限中枢，它有三个升级条件：
- 推广下级人数：A 推广 B，B 推广 C，系统记录上下级关系，算入“推广人数”。
- 自身消费：用户在自己的群或其他群消费，累计金额决定等级。
- 直接缴费：用户主动购买群等级，类似会员升级。
升级条件可以在后台配置权重。比如设置升级到 2 级群需要推广 5 人且消费满 300 元，或者直接缴费 99 元。这套逻辑的核心是：等级不是摆设，而是控制能力的开关。等级一变，建群数量、群人数上限、群费比例、分发商品数量都会跟着变。
在Class_Main.asp中，GetUserLevel()方法会读取用户当前等级，然后从数据库表sns_level中取出对应配置。表结构关键字段如下：
| 字段 | 含义 |
|---|---|
level_id | 等级编号 |
public_grp_num | 可建公开群数量 |
public_grp_limit | 公开群人数上限 |
private_grp_num | 可建私密群数量 |
private_grp_fee_max | 私密群最高群费 |
fee_percent | 系统扣费百分比 |
group_collect_enable | 是否允许群收款 |
self_products_num | 自发商品数量 |
dist_products_num | 分销其他群商品数量 |
stock_products_num | 备货给下级商品数量 |
2.3 等级配置的加载与缓存
inc.asp中会预加载等级表到应用级缓存，避免每个页面都查数据库。常见做法是在Application对象里存一个字典：
If IsObject(Application("BingSNS_Levels")) = False Then Set rs = Server.CreateObject("ADODB.Recordset") rs.Open "SELECT * FROM sns_level ORDER BY level_id", Conn, 1, 1 Dim levels Set levels = Server.CreateObject("Scripting.Dictionary") Do While Not rs.EOF levels.Add rs("level_id"), rs.GetRows() rs.MoveNext Loop Application.Lock Application("BingSNS_Levels") = levels Application.UnLock rs.Close End If这段代码把等级配置一次性读入内存。rs.GetRows()返回二维数组，取用的时候直接levels(level_id)就能拿到该等级的权限数组，比多次查询数据库快得多。注意Application缓存必须在后台修改等级配置后主动清空，否则用户升级时要等进程回收或手动重启站点。
3. 社群运营核心：聊天室、直播对接与群商品分销
3.1 群聊天室的消息模型与爬楼模式
聊天室不是简单的轮询，它支持文字、语音、图片、表情，还能把收款贴、悬赏贴、商品卡片插入消息流中。底层消息表sns_chat_msg的关键字段包括：
msg_type：1=文字，2=图片，3=语音，4=商品，5=收款贴，6=悬赏贴group_id：所属群user_id：发送人ref_id：当消息类型为商品时，存商品 IDis_reply：是否回复旧消息，用于爬楼模式
爬楼模式实现得比较巧妙：前端把当前消息所在楼层数发到服务端，查询时用AND msg_id > 楼层基准ID只拉增量。代码在merge.ashx里能看到类似逻辑：
function loadFloorMessages(groupId, baseMsgId) { $.ajax({ url: '/merge.ashx?action=chat_floor', type: 'POST', data: { group_id: groupId, base_id: baseMsgId, page_size: 50 }, dataType: 'json', success: function(res) { if (res.code === 1) { var html = ''; for (var i = 0; i < res.data.length; i++) { var m = res.data[i]; if (m.msg_type === 4) { html += '<div class="goods-card">商品：' + m.goods_name + ' 价格：' + m.goods_price + '</div>'; } else { html += '<div>' + m.nickname + ': ' + m.content + '</div>'; } } $('#chatBox').append(html); } } }); }这段逻辑说明聊天室拉取消息是服务端过滤增量，而不是前端拿全量再去重。base_id是当前消息列表最后一条消息的 ID，服务端只需要查WHERE msg_id > base_id AND group_id = ?，这样在网络较差时也不会丢消息。
3.2 第三方直播接入：Cls_Rtmp 与 Cls_M3U8 配置
群直播功能接入的是第三方直播平台，后台可以按群或全局绑定直播源。在a_Inc/Inc.asp里你会发现这两个变量：
' 直播源配置 - 请填写准确的推流地址 Cls_Rtmp = "rtmp://your-push-server.example.com/live/room1" Cls_M3U8 = "http://your-pull-server.example.com/live/room1.m3u8"这里有个容易踩的坑：Cls_Rtmp不是让你直接填播放地址，而是给 OBS 或手机推流端用的 RTMP 推流地址。Cls_M3U8才是普通用户浏览器里播放的 HTTP 流地址。两个地址需要你自己通过直播平台后台生成。系统只是把这两个字符串写到前端播放器：
<video id="livePlayer" class="video-js" controls preload="auto"> <source src="<%=Cls_M3U8%>" type="application/x-mpegURL"> </video>如果你用的不是 m3u8 而是 flv，就需要改成 http-flv 形式并配置对应的播放器插件。免费方案可以用 OBS 推流到 Nginx-RTMP 服务器，自己生成 m3u8，收费方案可以直接用云直播服务。关键在于输出给播放器的地址是拉流地址，不是推流地址。
3.3 群商品组成与供应价分佣逻辑
群商品的来源只有三类：自身发布、分销平台或其他社群商品、上级备货。每种商品发布前都要设一个“供应价”，这个价格不是给终端买家看的，而是预留给下游分销商的一键采购成本价。也就是如果把商品挂到分销市场，其他群主看到的就是“供应价 + 建议售价”。当下游群卖出后，系统自动计算利润分配。
3.3.1 分销层级与佣金计算公式
假设商品最终售价为P，供应价为S，系统扣费百分比为R，分佣级数为N，每级佣金比例为C1, C2, ..., CN。那么卖出商品后：
- 分销商毛利 =
(P - S) × (1 - R) - 第 i 级分佣 =
(P - S) × Ci
这个计算逻辑在Class_Main.asp的CalcCommission()方法里。实际写 SQL 时，可以考虑用存储过程统一处理，避免 PHP 代码里多次查表造成超卖：
DELIMITER $$ CREATE PROCEDURE `sp_calc_commission`( IN order_id INT ) BEGIN DECLARE product_price DECIMAL(10,2); DECLARE supply_price DECIMAL(10,2); DECLARE sys_fee_rate DECIMAL(5,2); SELECT p.price, p.supply_price, s.fee_percent INTO product_price, supply_price, s_fee_rate FROM order_item oi JOIN products p ON oi.product_id = p.id JOIN sns_group g ON oi.group_id = g.id JOIN sns_level s ON g.level_id = s.id WHERE oi.id = order_id; INSERT INTO commission_log (order_id, user_id, level, amount, create_time) SELECT order_id, referrer_id, 1, (product_price - supply_price) * (1 - sys_fee_rate) * 0.2, NOW() FROM user_relation WHERE user_id = (SELECT buyer_id FROM orders WHERE id = order_id); END$$存储过程的好处是把“商品价、供应价、群等级扣费比例、上下级关系”放在同一事务里，保证佣金不会因为并发查改而错乱。如果你的环境不支持存储过程，也可以用 ASP 事务包裹多个 UPDATE，但性能会比这个做法差。
4. 层级分佣与财务结算：从下单到提现的完整链路
4.1 两级推荐关系：平台推荐与群推荐
系统里存在两套独立的推荐关系，这是最容易搞混的地方。
- 平台推荐关系：全局用户上下级，A 推 B，B 推 C。当平台自营商品或平台活动促销被消费时，佣金按这个关系分配。
- 群推荐关系：同一个群内的上下级，A 拉 B 进某个群，B 拉 C 进同一个群，形成群内树形关系。当群成员在群内消费时，佣金按群关系分配。
为什么要分开？因为一套关系无法处理“跨群分销”的场景。比如 D 在群里买了商品，这个商品是 E 分销进来的，那佣金既要分给 E，也要分给 D 在群里的上级。平台关系表和群关系表需要分开存储：
CREATE TABLE `sns_refer_platform` ( `id` INT NOT NULL AUTO_INCREMENT, `user_id` INT NOT NULL, `parent_id` INT NOT NULL, PRIMARY KEY (`id`), KEY `idx_user` (`user_id`) ); CREATE TABLE `sns_refer_group` ( `id` INT NOT NULL AUTO_INCREMENT, `group_id` INT NOT NULL, `user_id` INT NOT NULL, `parent_id` INT NOT NULL, PRIMARY KEY (`id`), KEY `idx_group_user` (`group_id`, `user_id`) );平台关系是全站唯一树，群关系是每个群独立一颗树。查询群关系时一定要带group_id条件，否则会串群。
4.2 订单处理与群主收益组成
群主收益不是单靠卖货。源码里群主的财务数据分为四块：
- 自发商品利润：售价 - 成本
- 分销商品利润：售价 - 供应价 - 系统扣费
- 私密群群费：全额或按比例
- 群收款和付费问答：按系统扣费比例分成
典型场景：群主把商品 A 挂到自己群里，成本 50 元，售价 100 元，那么利润 50 元全额归群主；如果群主把另一个社群的商品 B 分销进来，B 的供应价 60 元，售价 100 元，系统扣点 10%，那么群主毛利就是(100-60)*0.9=36元。这条逻辑在后台的“订单详情”页里会有明确拆分。
4.2.1 自发商品与分销商品利润差异
在代码层面，order_item表需要标记item_source字段，值为self或dist。处理退款时两者逻辑也不同：自发商品退款时，群主损失全部利润；分销商品退款时，要联动扣回上级佣金。建议在Class_Main.asp的退款方法里先调佣金回滚，再改订单状态，顺序反了会导致分佣日志无法核对。
4.3 实时提现接口与结算字段配置
系统支持实时提现到微信或支付宝，本质是接第三方支付企业付款接口。inc.asp里需要配置商户号、API 密钥、证书路径。提现请求在merge.ashx?action=cashout中处理，核心逻辑是：
Function SendWeixinCashout(user_id, amount) ' 校验用户余额 Dim balance balance = GetUserBalance(user_id) if amount > balance Then SendWeixinCashout = "余额不足" Exit Function End If ' 调用企业付款接口 Dim data data = "mch_id=" & WxPayMchId & "&partner_trade_no=" & GenTradeNo(user_id) & "&amount=" & amount * 100 & "&desc=BingSNS提现" Dim xmlResult xmlResult = HttpsPost(WxPayApiUrl, data) ' 解析结果 If InStr(xmlResult, "SUCCESS") > 0 Then DeductBalance user_id, amount SendWeixinCashout = "ok" Else SendWeixinCashout = "fail" End If End Function注意amount单位是元，但微信接口要求单位是分，代码里做了amount * 100转换。提现前必须做余额校验和幂等票据，否则用户快速点击两次就会发出两笔。GenTradeNo(user_id)要保证唯一，最好用时间戳 + 用户ID + 随机数。
5. 部署排错与二次开发：VS2010+MySQL 环境下的实战技巧
5.1 Inc.asp 关键配置项详解
a_Inc/Inc.asp是唯一必须手工改的配置文件。除了数据库连接和微信 Token，还要注意以下两个配置：
Const SiteDomain = "https://your-domain.com" ' 网站域名，统一带协议头 Const WxToken = "your_wechat_token" ' 微信公众号 TokenSiteDomain会用于生成二维码和分享链接，如果填错会导致推广二维码扫码后跳到错误域名。WxToken要和你微信公众平台后台填写的 Token 完全一致，否则服务器无法响应微信服务器验证。
5.2 微信公众账号 Token 对接
微信对接是接入流程的第二步。系统会提供一个接收微信消息的 URL，通常是merge.ashx?action=weixin。微信服务器在首次配置时会 GET 请求这个地址，带signature、timestamp、nonce、echostr参数。源码中验证逻辑会读取inc.asp里的 Token 做 SHA1 加密比对，比对成功返回echostr。这里最容易出错的是inc.asp文件编码。如果文件是 ANSI 编码，你把它改成 UTF-8 保存，Token 尾部会多出不可见字符，导致校验失败。建议用 VS2010 打开文件另存为 UTF-8 with BOM，避免中文乱码和 Token 尾部差异。
5.3 静态化与 SEO：Wangpu.zzs.asp 的热帖缓存
PC 端热帖静态化是为了让搜索引擎能抓到帖子内容，而不是等用户点击才生成页面。Wangpu.zzs.asp是网铺页的静态化模板，它会在第一次被请求时生成 HTML 文件，后续请求直接读取静态文件。生成逻辑在Class_Main.asp的BuildStaticPage()方法里：
Sub BuildStaticPage(htmlPath, content) Dim fso, file Set fso = Server.CreateObject("Scripting.FileSystemObject") Set file = fso.CreateTextFile(Server.MapPath(htmlPath), True, True) file.Write content file.Close Set file = Nothing Set fso = Nothing End SubCreateTextFile第三个参数True表示以 Unicode 格式写入。如果你生成的静态页面出现乱码，检查这里是否改成了False（ASCII/ANSI）。通常建议统一用 UTF-8，并在每个页面顶部加<meta charset="utf-8">。静态化的粒度按群和帖子的热度来定，热门群首页可以在后台一键生成，冷门群用动态请求。
5.4 常见错误与排查方法
| 现象 | 可能原因 | 排查命令 |
|---|---|---|
| 首页白屏 | inc.asp数据库连接错误 | 在Inc.asp后面加Response.Write(Conn.State)测试 |
| 微信 Token 验证失败 | Token 不一致或文件编码错误 | 输出SHA1(timestamp+nonce+token)与签名比对 |
| 直播无法播放 | Cls_M3U8地址错误或跨域 | 在浏览器控制台看网络请求，确认 m3u8 加载状态码 |
| 佣金计算异常 | 群等级缓存未刷新 | 重启 IIS 或手动执行Application.Contents.Remove("BingSNS_Levels") |
| 提现成功但余额未扣 | 事务未提交 | 检查DeductBalance是否在成功回调里执行 |
最后一个常见坑是 MySQL 连接池。经典 ASP 使用ADODB.Connection时，如果连接未显式关闭，高并发下会报“操作发生意外”。建议每个方法末尾强制Conn.Close，并在Class_Main.asp里写一个SafeClose包装函数。部署到 Windows Server 时，确认 IIS 的应用程序池使用 32 位模式，因为很多旧版 MySQL ODBC 驱动只有 32 位，否则连接会一直失败。
二次开发前，先跑通一个完整的用户升级链路：用户注册 -> 推广下级 -> 升级等级 -> 建群 -> 发布商品 -> 分销 -> 提现。这条链路走通后，再改其他功能就不容易破坏核心逻辑。
本文还有配套的精品资源，点击获取
