简介一套完整的卡密社区SUP系统总控与主站分销源码专为需要搭建卡密自助交易、分站分销业务的开发者或站长准备。系统涵盖总控端、主站后台和分站后台三套管理界面可实现系统商模式的平台分配、卡密发行、分站开通与API对接配合自助发卡与卡密交易流程适合虚拟商品在线销售场景如游戏点卡、激活码、会员时长等。包内共2000个文件以PHP业务代码、JS前端脚本、CSS样式和HTML页面为主另含MD说明文档、JSON配置、SQL数据库脚本及Nginx相关配置压缩包约62.84MB整体目录结构清晰便于按模块定位代码。源码基于PHP/MySQL体系构建具备基础运维能力的读者即可完成部署和二次修改已有296人下载学习借助总控-主站-分站的多层级设计可快速开展卡密批发与分销业务并通过内置API文档扩展支付、查询等功能。1. 卡密社区SUP系统总控和主站分销为什么必须拆成两套标题里“卡密社区SUP系统总控源码主站分销系统功能源码”其实说了两件事总控管卡密资产主站管售卖和代理分佣。很多自己写过发卡站的人都有教训把卡密生成、订单、代理都塞进一个 PHP 项目里出一次 SQL 注入卡密池和后台密钥一起被拖走或者代理后台和下单价目耦合分销计算改一版就崩一次。拆分之后总控是唯一的卡密发证方主站只是销售端和分佣端两边通过带签名的 API 对话。本文从数据表、签名、API 鉴权写到联调参数和验证清单适合正在做虚拟商品交易或社区积分系统的后端开发者参考。2. 总控源码落地卡密池、签名与总控API设计2.1 卡密表结构与状态机设计总控最核心的资产不是卡密本身而是“卡密状态的流转记录”。只要状态机设计错后面做补卡、退款、对账都会失控。我一般把卡密表设计成一张宽表把与核销相关的字段都放在同一行减少跨表查询。CREATE TABLE card_pool ( card_id bigint unsigned NOT NULL AUTO_INCREMENT, card_key varchar(64) NOT NULL COMMENT 卡密明文格式自定义, card_secret varchar(64) NOT NULL COMMENT 卡密密钥或签名后缀, product_id varchar(32) NOT NULL COMMENT 产品标识用于区分时长/权益, batch_id varchar(32) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待售 1已售未激活 2已激活 3已核销 4已冻结 5已退款, duration_days int NOT NULL DEFAULT 0, owner_uid bigint NOT NULL DEFAULT 0 COMMENT 当前持有者用户ID, source_agent_id bigint NOT NULL DEFAULT 0 COMMENT 卡密来源代理ID, activated_at datetime DEFAULT NULL, expires_at datetime DEFAULT NULL, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_card_key (card_key), KEY idx_status_owner (status, owner_uid), KEY idx_batch (batch_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT卡密池;卡密的状态机必须只允许单向前进待售 - 已售未激活 - 已激活 - 已核销。已核销不能回退退款只能从已售未激活退到待售。把这条规则写在总控的更新条件里而不是写在业务代码里避免多个主站节点同时操作同一条卡密。UPDATE card_pool SET status 1, owner_uid :buyer_uid, source_agent_id :agent_id, updated_at NOW() WHERE card_id :card_id AND status 0;这里用status 0作为乐观锁条件。如果 update 影响行数为 0说明卡密已被其他订单抢占主站需要重新取卡。这是“卡密不超卖”的最后一道屏障上游可以用 Redis 预扣但数据库状态锁必须保留因为最终对账以数据库为准。2.2 HMAC-SHA256签名生成与验签实现卡密社区 SUP 系统里卡密不能只是一串随机字符串否则打开数据库的人可以直接批量伪造新卡密。常见做法有两种第一种是 HMAC-SHA256主站和总控共享一个 app_secret第二种是 RSA 私钥签名总控持有私钥主站只持公钥验签。如果主站代码也可能泄露RSA 更安全因为主站无法生成合法卡密。这里给一个 Python 的生成端示例对应总控里的离线发卡脚本import hashlib import hmac import os from datetime import datetime, timedelta SECRET_KEY os.environ[SUP_MASTER_SECRET] def generate_card(product_id: str, duration_days: int) - dict: raw os.urandom(16).hex().upper() card_key f{product_id[:2]}-{raw[:8]}-{raw[8:12]} expires_at datetime.utcnow() timedelta(daysduration_days) expires_ts int(expires_at.timestamp()) # 把产品ID、卡密明文、过期时间一起做签名 payload f{product_id}:{card_key}:{expires_ts} signature hmac.new( SECRET_KEY.encode(), payload.encode(), hashlib.sha256 ).hexdigest() card_secret signature[:24] return { card_key: card_key, card_secret: card_secret, product_id: product_id, expires_at: expires_ts, }注意这里card_secret不是随机串而是签名的一部分。当用户在主站激活卡密时主站把card_key card_secret product_id expires_at发给总控总控用同一个 secret 重新算一遍 HMAC比对前 24 位是否一致。这样做的好处是即使某条卡密在数据库里被篡改了过期时间签名校验也会失败因为expires_ts参与签名改一个字符整个 signature 都对不上。如果追求更严直接换成 RSA 私钥签名。总控生成时用rsa模块私钥对卡密信息签名主站验签时用只读公钥。代价是签名和验签速度慢但对卡密平台每秒几千次的校验量完全够用。2.3 总控API的鉴权与关键参数总控对外开放的接口不要多三个就够了verify验证卡密是否可用、activate激活并绑定用户、deactivate按订单退款作废。每个接口都必须是幂等操作因为主站可能因网络重试而重复请求。接口鉴权除了 app_secret还要加时间戳防重放。我用固定的请求头方案POST /openapi/v1/card/verify Content-Type: application/json X-App-Id: main_site X-Timestamp: 1710000000 X-Signature: 9f86d081884c7d659a2feaa0c55ad015... { request_id: order-20240311-001, card_key: VIP-AB12CD34, card_secret: 27fa9c4c1e2f, product_id: VIP_MONTHLY }签名计算规则把X-Timestamp和请求体 JSON 字符串拼接再用 app_secret 做 HMAC-SHA256。主站每次请求前生成时间戳总控收到后检查偏差不超过 300 秒同时用 Redis 记录request_id已处理过的请求直接返回缓存结果。参数含义典型值X-App-Id主站身份标识用于区分多个主站main_siteX-Timestamp请求发起 Unix 秒级时间戳1710000000X-Signature对 timestamp body 的 HMAC 签名64 位十六进制request_id幂等键建议用订单号随机后缀order-1710000000-abc总控在验签通过后还需要做一次风控检查同一 IP 激活失败的次数、同一卡密查询频率、短时间内大量不同卡密提交。免费卡密发放平台经常被脚本扫卡如果总控不做频控别人可以把你的卡密池当字典攻击。3. 主站分销系统源码代购、分佣和卡密库存扣减3.1 代理关系与分佣层级表主站分销的核心是“谁带来订单”和“从哪个库存里发卡”。很多源码把代理直接挂在用户表里用pid表示上级但分销等级、提现状态一多用户表就乱。常见做法是单独建代理映射表代理关系变更不影响用户主表。CREATE TABLE agent_relation ( id bigint unsigned NOT NULL AUTO_INCREMENT, agent_id bigint NOT NULL COMMENT 代理用户ID, parent_id bigint NOT NULL DEFAULT 0 COMMENT 上级代理ID, level tinyint NOT NULL DEFAULT 1 COMMENT 分销层级1一级 2二级, commission_rate decimal(6,4) NOT NULL DEFAULT 0.1000 COMMENT 分佣比例, status tinyint NOT NULL DEFAULT 1, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_agent (agent_id), KEY idx_parent (parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;分销层级不要设计成无限嵌套无限嵌套在结算时会出现递归深循环而且很容易被恶意刷出多级分佣。卡密类产品利润薄一级分佣加二级分佣基本到底超过两级的订单在结算时直接按系统归零。代理升级时只更新level和commission_rate不要改parent_id否则整个分佣链路都要重算。3.2 卡密采购下单与总控库存预占主站拿到代理订单后需要先向总控申请“锁定卡密”然后才能真正收款。顺序不能反过来否则代理付了钱总控那边库存已经卖完主站就得赔卡或者退款。下单接口逻辑我一般这样安排def create_order(agent_id, product_id, quantity): # 1. 检查代理账户余额或支付状态 # 2. 调用总控预占库存 reserve call_sup_api( path/openapi/v1/card/apply, payload{ request_id: fapply-{agent_id}-{time.time_ns()}, product_id: product_id, quantity: quantity, owner_uid: str(agent_id), } ) # 3. 本地创建待支付订单保存总控返回的卡密ID order_id save_order(agent_id, product_id, quantity, reserve[card_ids]) # 4. 返回支付二维码 return order_id总控的/apply接口在设计上必须返回具体的卡密 ID 列表而不是只返回一个“剩余数量”。因为主站拿到卡密 ID 后要落库到order_card表支付完成再向总控确认激活如果支付超时主站再调/release把卡密释放回池子。主站库存扣减不要直接 UPDATEcard_pool SET status2而是用状态条件更新。因为卡密可能同时被多个主站节点用同一个代理 ID 请求条件更新只能成功一个。扣减后要读取受影响行数等于 0 就说明这次申请已经过期需要重新取卡。3.3 分佣结算的时机和事务边界分佣结算最容易犯的错是在订单支付回调里直接写余额然后回调重试时又加一遍。常见做法是引入结算流水表支付回调与分佣写入放在同一事务用订单号做唯一索引保证只结算一次。CREATE TABLE agent_commission_log ( id bigint unsigned NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL, agent_id bigint NOT NULL, amount decimal(12,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待结算 1已入账, from_parent bigint NOT NULL DEFAULT 0, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_agent (order_id, agent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;结算动作放在支付回调之后的异步队列里避免用户支付成功却卡在分佣等待。队列消费者先尝试插入agent_commission_log如果唯一索引冲突说明已经处理过直接跳过插入成功后再更新代理余额。两步操作不在同一事务也不会重复因为唯一索引就是幂等锁。另外一个细节分佣金额不要用订单实付金额直接乘比例而要减去卡密成本再乘比例。例如代理下单成本 50 元卡密池货源成本 30 元一级分佣按 10% 应该是(50 - 30) * 0.1而不是50 * 0.1。这个边界在 SUP 类系统里经常被忽略导致平台亏本代发。4. 总控与主站联调中的3个关键参数和4个坑4.1 回调地址、幂等键、时间窗是必调的3个参数总控和主站之间不是只有同步请求卡密激活或者退还时总控需要回调主站。回调地址必须写在总控配置里不能写死在前端或商户请求里否则别人可以冒用总控身份给主站发伪造激活通知。回调的幂等键建议用order_id card_id action三个字段拼成。主站收到回调后先查库如果这个组合已经处理过直接返回成功。主站应答总控时状态码 200 不代表总控任务成功总控要在响应体里看到类似{code:S_OK}才停止重试。建议两个系统联合约定业务成功才返回 200业务失败也返回 200 但 code 不同HTTP 层不区分业务状态。时间窗参数则是X-Timestamp的最大偏差。生产环境我一般设为 600 秒太短会因主站和总控的服务器时钟不一致导致频繁验签失败太长又失去防重放意义。设置前先用 NTP 把两台服务器时间对齐偏差量级在 50 毫秒内最合理。参数名配置位置建议值调节依据回调地址总控后台https://main.example.com/callback/sup必须 HTTPS幂等键请求体字段order_id card_id action幂等键冲突时直接忽略时间窗总控验签逻辑600 秒服务器时钟漂移严重时调大请求超时主站调用总控3000 ms总控耗时不超 200ms4.2 超卖、重复通知、时间偏移、卡密已兑现这四个坑超卖是最隐蔽的坑。主站内存里维护库存数量多个代理同时下单时各自扣减剩余库存看起来没超到总控取卡时发现数量不够。解决办法是前面 3.2 的状态条件更新以及总控的/apply接口内部用SELECT ... FOR UPDATE锁住卡密池的分页区间直到返回卡密 ID。注意锁不能覆盖全表否则高并发时总控变成单线程。重复通知的坑在免费卡密发放场景尤其常见。总控重试回调时如果主站没有幂等同一个激活事件会被拆成多笔分佣。所以在 3.3 的agent_commission_log里加上唯一索引然后在回调处理函数里先插记录再发分佣重复请求自然被索引拦掉。时间偏移会直接让签名验不过。主站服务器时间慢了 10 分钟总控收到X-Timestamp时已经超过时间窗所有请求都提示签名无效。排错时不要只查代码先对比两台服务器date -u输出再看 NTP 服务状态。曾经见过主站部署在 Windows 容器、时间同步关闭导致联调一整天都在猜签名格式问题。卡密已兑现的问题出现在退款和换卡流程。用户退款后总控把卡密标成已退款但主站本地没同步卖家用同一个卡密文件去补卡主站再次申请激活时总控报错。处理方式是在总控的激活逻辑里增加source_request_no字段同一个订单号不能激活两张不同卡密这样即使主站发错卡总控也会拒绝。5. 把总控安全加固到生产级的验证核对单总控和主站分开后安全重心在总控。开发调试时可以暂时用明文密钥上线前至少做一轮下面的验证。每个检查项都要有预期结果不能只写“通过”。检查项验证方法预期结果卡密签名密钥分离主站配置里只能有 RSA 公钥或 HMAC secret主站用私钥/主密钥无法对卡密重新签名卡密状态机约束对card_pool执行强制执行 UPDATE 的 SQL数据库层拒绝从 3 回退到 0API 幂等用同一个request_id连续发送 10 次激活请求只激活 1 张卡密返回相同结果时间戳防重放截获一个合法请求3 小时后再发送总控返回timestamp expired回调重复支付伪造两笔相同回调到主站分佣接口第二笔响应 code 为S_DUP代理越权查询用低级代理 token 请求其下级的卡密列表返回 403 或空数据最后一个常被忽略的动作总控的管理端登录日志。SUP 系统里总控管理台如果被爆破攻击者不需要解密卡密直接在页面上重新生成一个批次就行。所以我总是把总控登录的 IP、UA、操作类型写入独立的审计表并且不和卡密业务表放在同一个数据库实例里。上线后每隔 7 天查看一次审计表里是否有批量操作记录能提前发现异常发卡行为。本文还有配套的精品资源点击获取