简介草莓CDMS是一套基于ThinkPHP 5.1、EasyWechat 4.0、Swoole与Redis构建的原创内容分销系统面向需要搭建微信小说、漫画、有声、影视等分销平台的开发者与运营团队。系统支持微信开放平台扫码授权和微信公众平台手动对接两种模式并提供平台方、版权商、合作商、渠道商、代理商五种角色权限配合订单、用户、下线、内容、扣量等统计模块可覆盖内容付费、渠道推广、代理分成等常见分销业务场景。包体共5个文件、约37.86MB包含项目源码、安装必读txt、使用说明html、Swoole Loader扩展so以及框架压缩包可在本地或服务器环境完成部署与二次开发适合作为微信内容分销业务的快速起步模板。已有147人学习/下载适合希望快速掌握ThinkPHP 5.1与Swoole/Redis集成方式或需要参考多角色分销权限设计与微信公众号对接实现的开发人员。1. 草莓CDMS在微信里跑通小说分销闭环的一套系统“草莓CDMS”这个名字第一次见很多人会以为是套普通 CMS 建站程序。实际它做的是内容分销这件事把小说内容拆成可售卖的章节读者在微信公众号里打开一个 H5 书城免费读几章后付费解锁。每个分享出去的链接自带上下级绑定关系成交后系统自动给分销员分佣。这个模式就是微信小说平台系统的核心闭环v1.0 的边界很清晰只服务公众号 H5 场景不做小程序端、不做独立 App。适合谁用手里有小说版权的版权方以及有公众号流量但缺内容的运营团队——前者需要渠道后者需要货草莓CDMS 把两边的分账逻辑和内容交付一次打通。2. 先打通微信授权openid 才是分销归因的真正钥匙2.1 为什么要拿 openid而不是手机号分销系统的首要问题是归因一个订单到底算谁推广的常规做法是打开书城时先绑定邀请关系但微信生态里不能默认拿到用户手机号必须用户主动授权。而 openid 是微信用户在这个公众号下的唯一标识拿来做分销归因最稳定。读者第一次访问书城时URL 里带一个 inviter 参数后台拿这个参数和 openid 做绑定之后所有订单都按这个绑定关系走。这里用的是公众号网页授权 OAuth2.0 的静默授权 scopesnsapi_base用户无感知只需在微信客户端里跳转一次授权 URL回调后就能拿到 openid不需要用户手动点同意转化路径最短。2.2 静默授权回调与分销关系绑定代码常见做法是写两个 PHP 入口一个负责拼接授权跳转链接一个处理微信服务器回调。跳转参数里必须带上 state用来回传分销来源防止回调后把上下级关系丢掉。// auth_redirect.php引导用户进入微信授权页 $appid wx1234567890abcdef; $callback https://static.example.com/callback.php; $inviter isset($_GET[inviter]) ? intval($_GET[inviter]) : 0; $state base64_encode(json_encode([inviter $inviter, ts time()])); $url https://open.weixin.qq.com/connect/oauth2/authorize . ?appid . $appid . redirect_uri . urlencode($callback) . response_typecode . scopesnsapi_base . state . $state . #wechat_redirect; header(Location: . $url);这个脚本只做跳转不落任何业务数据。state 里存分销员 ID 和时间戳回调时再解开。注意 redirect_uri 必须做 URL 编码且域名一定要在公众号后台「网页授权域名」里配置过否则微信直接提示 redirect_uri 参数错误。授权链接的 #wechat_redirect 后缀必须保留去掉后在某些微信版本里会出现白屏。// callback.php用 code 换 openid并绑定分销关系 $code $_GET[code]; $state json_decode(base64_decode($_GET[state]), true); $inviter isset($state[inviter]) ? intval($state[inviter]) : 0; $tokenUrl https://api.weixin.qq.com/sns/oauth2/access_token . ?appid . $appid . secret . $secret . code . $code . grant_typeauthorization_code; $resp file_get_contents($tokenUrl); $data json_decode($resp, true); $openid $data[openid] ?? ; if ($openid ) { // 拉取失败通常出现在 code 被二次使用或过期直接停止 exit(授权失败请重新进入书城); } if (!userExist($openid)) { createUser($openid, $inviter); // 新用户记录上级 } else { // 老用户不允许被反复改绑防止分销员互抢 bindInviterOnce($openid, $inviter); }code 只能用一次有效期为 5 分钟回调里拿到 openid 后应立即落库。老用户绑定的原则是“只认第一次”所以 createUser 里如果发现用户已存在就只补关系不覆盖关系。分销绑定表建议字段为uid、openid、inviter_uid、bind_time、unlock_timeunlock_time 用来控制绑定期限比如 30 天内有效超时后新订单不再给原上级分佣。2.3 登录态失效与多端会话冲突现象一读者在书城里停了很久再去解锁章节时提示“请重新进入”。原因是 openid 拿到了但服务端登录态 token 过期了。解决把 token 有效期拉长并在每次页面请求里做滑动续期只要用户 30 分钟内有操作就刷新过期时间。现象二同一个微信号在安卓和电脑端微信里同时打开书城后台出现两个 session分销关系有时绑到新 session 上。原因是登录态只存在 cookie 里跨端不共享。解决以 openid 为唯一身份键session 只存 openid业务表全部按 openid 查询不依赖 session 里的其他字段。这样跨端只是换设备身份不会丢。3. 付费阅读与微信支付从章节解锁到回调幂等3.1 章节鉴权与免费试读策略小说平台常见的解锁策略是“前 N 章免费后续按章付费”。章节表 chapter 需要保存 sort_no、is_free、price 三个核心字段用户解锁表 user_unlock 记录 uid、chapter_id、order_id、unlock_time。读者请求章节内容时先判断是否免费再判断 user_unlock 是否存在都不满足就返回“需要解锁”并弹出支付页。注意免费章数量不要设在 3 章以下转化率会明显下降也不要超过 10 章付费渗透率会被拉低。我一般建议新书前 5 章免费中间每隔 20 章再放 1 章免费用于挽回流失读者。3.2 JSAPI 支付下单必填参数与签名顺序在微信内 H5 支付只能用 JSAPI 支付拉起收银台之前要调统一下单接口拿 prepay_id参数里最容易被忽略的是用户 openid 必须与当前公众号一致否则报“openid 与 AppID 不匹配”。// pay_order.php下单并返回支付参数 $orderId createOrder($uid, $chapterId, $price); // 生成业务订单 $params [ appid $appid, mch_id $mchId, nonce_str md5(uniqid()), body 小说章节解锁, out_trade_no $orderId, total_fee $price, // 单位是分不是元 spbill_create_ip getClientIp(), notify_url https://pay.example.com/wxnotify.php, trade_type JSAPI, openid $openid, ]; ksort($params); // 字典序排序字母升序 $stringA urldecode(http_build_query($params)); $stringSignTemp $stringA . key . $apiKey; $params[sign] strtoupper(md5($stringSignTemp)); $xml arrayToXml($params); $resp postXml(https://api.mch.weixin.qq.com/pay/unifiedorder, $xml); // 解析出 prepay_id 后再组一次前端拉起支付用的参数total_fee 单位是分传 1 就是 0.01 元。签名前必须先做 ksort 字典序排序拼接时不要漏掉最后追加的 API 密钥。我踩过最隐蔽的坑是http_build_query 默认会对参数做 URL 编码但微信官方示例是不编码直接拼接的所以这里要 urldecode 一次再拼 key签不对时优先查这里。下单成功后返回 prepay_id再用 prepay_id、nonce_str、timeStamp 组装拉起支付所需的 paySign这段参数顺序和下单签名不完全一样必须单独实现。3.3 回调验参与幂等处理支付成功后微信会请求 notify_url回调里必须先验签再判断订单金额是否一致最后查询微信侧订单状态不能只凭回调内容就入账。回调脚本的幂等很关键微信回调可能重复推送客户端也可能主动查单处理函数里要保证同一订单只能入账一次。// wxnotify.php验签、查单、幂等入账 $xml file_get_contents(php://input); $data xmlToArray($xml); // 第一步验签失败则返回失败报文让微信重试 if (!checkSign($data)) { respondFail(sign error); } // 第二步金额比对回调金额与订单原价不一致直接拒绝 $order getOrder($data[out_trade_no]); if ($order[amount] ! intval($data[total_fee])) { respondFail(amount mismatch); } // 第三步查微信侧订单真实状态 $queryResp queryWxOrder($data[out_trade_no]); if ($queryResp[trade_state] ! SUCCESS) { respondFail(wx order not success); } // 第四步幂等入账order_state 从 0 改为 1 必须带条件更新 $affected updateOrderState($order[id], 1, 0); // where state0 AND idxxx if ($affected 0) { giveUserChapter($order[uid], $order[chapter_id]); } respondSuccess();为什么一定要条件更新如果回调重复进入第二次 updateOrderState 影响行数是 0就不会重复给章节、重复加余额。这样比“先查再改”更稳因为并发下两个请求可能同时查到 state0然后都去更新。带 where state0 的条件更新把并发问题挡在数据库层面。响应报文必须是微信规定的 XML 格式且 code 为 SUCCESS否则微信会按策略重试若干次重试次数多了还会进风控名单。3.4 支付环节的三个常见坑第一个坑是支付授权目录没配好只能配到项目根目录导致子页面拉起支付时提示“当前页面的 URL 未注册”。解决支付目录尽量配到根目录而不是某个具体控制器。第二个坑是下单接口返回“appid and mch_id not match”通常是用了不同主体的公众号 AppID 和商户号。第三个坑是前端拿到 prepay_id 但 paySign 错误常见原因是二次签名时把 appId 写成了 appid微信要求字段名是 appId大小写错一个字符就报签名错误。4. 分销分佣与提现两级分佣怎么算才不亏4.1 分销员体系与绑定失效规则分销模式不能套传销逻辑行业内目前最稳的是两级分佣读者通过分销员 A 的链接进入A 获得一级佣金如果 A 再发展出自己的下线 BB 产生的订单A 拿二级佣金B 拿一级佣金。三级以上不仅用户信任度低也容易触发平台风控。v1.0 的分销员申请有两种方式一是用户主动申请需要满足已消费满某金额二是被邀请后自动成为分销员。绑定关系默认 30 天有效到期后该读者的新订单不再给原上级分佣但期间已成交的订单不受影响。这个设计是为了防止“一绑终身”老分销员躺着吃新流水的模式会让团队失去推广动力。4.2 佣金结算的表结构与代码实现佣金结算要解决三件事给上级加余额、记流水、防止同一订单重复结算。表结构上拆成四张orders 存订单金额与用户user_wallet 存用户可用余额wallet_log 存每一笔收入支出流水dist_relation 存上下级绑定关系。订单回调成功后触发结算核心代码用事务包裹。// distribute.php订单支付成功后执行分佣 function settleCommission($orderId) { $order getOrder($orderId); if ($order[distributed] 1) { return; // 已分佣直接跳过 } $level1Rate 0.30; // 一级佣金比例 $level2Rate 0.10; // 二级佣金比例 $relation getRelationByReaderUid($order[uid]); if (!$relation || $relation[expired] 1) { markOrderDistributed($orderId); return; // 无有效上级则不分佣 } // 上级分佣 $c1 round($order[amount] * $level1Rate, 2); addWallet($relation[inviter_uid], $c1, order, $orderId, level1); // 上上级分佣 if ($relation[inviter_uid] 0) { $upper getRelationByUid($relation[inviter_uid]); if ($upper $upper[expired] 0) { $c2 round($order[amount] * $level2Rate, 2); addWallet($upper[inviter_uid], $c2, order, $orderId, level2); } } markOrderDistributed($orderId); }addWallet 内部必须开事务先锁用户钱包行再更新余额再插入流水。这样即使脚本异常退出流水和余额也是一致状态。round 保留两位小数比例回调都从配置文件读取不要在代码里写死方便运营调整。分佣比例我习惯设成一级 30%、二级 10%再留一部分利润覆盖渠道成本和退款风险。佣金比例超过 50% 是很危险的一旦退款率超过 10%整个账很容易算成负毛利的。4.3 提现审核与封账提现走人工审核而不是自动打款是 v1.0 最稳妥的做法。用户提交提现申请后后台出现待审核记录运营核对分销数据后打款再把状态置为 completed。这里要防的是重复打款打款动作和状态更新必须绑在一起。我建议提现申请表加一个 audit_version 字段每次审核操作都带上版本号用条件更新置状态只有影响行数为 1 时才去调用打款接口。另外每天要做一次封账操作下午三点前申请的提现当天处理三点后的次日处理避免运营操作时金额一直在变。4.4 防刷单异常订单的排查顺序刷单是分销系统跑起来后必然会遇到的问题。常见刷法是用多个小号重复购买最低价章节拿佣金再申请提现。排查顺序固定为先看同一 IP 下订单数量是否异常再看同设备指纹下绑定的 openid 数量最后看分销员下游订单比例是否过高。三个条件都异常的直接标黑。更前置的防御是在注册时校验每个微信 openid 只能绑定一个钱包同一设备指纹绑定的账号超过三个就触发人工审核。v1.0 不做实时风控但至少要把这些字段都存下来后面接风控规则时才不用补数据。5. 上线前的常见问题排查域名拦截、分享链接与支付回调5.1 微信域名拦截检测链接在微信内打不开现象读者把分享链接发到群聊点击后微信直接提示“该网页已被拦截”或弹出非微信内置浏览器的风险提示。原因域名被多人举报、推广内容触发了平台规则或同一域名短时间内被大量分享。解决上线前先用域名拦截检测工具做一次体检把整站 URL 和分享链接都放进去查一遍。这类工具可以检测域名当前是否在拦截名单内以及被拦截的具体页面路径。更关键的是提前准备备份域名主域名一旦出事把分享链接书城入口切到备份域名同时保留支付回调域名不动避免支付配置全部重来。分享出去的每一篇文章都要控制在明显合规的尺度内标题和封面不要用夸张的诱导点击词否则被举报后连申诉都难。5.2 微信内置浏览器识别UA 字段不能当安全边界现象服务端用 PHP 判断是不是微信内置浏览器来区分支付方式但某些环境下安卓的 QQ 浏览器也能通过 UA 判断导致跳错支付方式。原因是 UA 完全可伪造任何客户端都能假装自己是微信。解决UA 判断只作为体验优化依据不作为支付安全的判断依据。真正判断支付环境要在前端拉起支付时就区分JSAPI 必须运行在微信内H5 支付用于非微信浏览器不要把 UA 和支付类型强绑定。后台统计里记录 UA 只是为了分析读者来源如果要识别真实微信环境可以用微信 JS-SDK 的接口能力来二次确认但这也有版本兼容问题所以我的做法是UA 只用来切 UI 提示和跳转逻辑订单创建始终以 openid 为唯一凭证不信任任何前端传来的环境标识。5.3 支付签名与回调地址两个最容易翻车的配置现象上线当天用户买不了章节后台日志全是“签名错误”和“redirect_uri 参数错误”。原因是我当时把几个配置混在一起填了支付授权目录填成了二级目录网页授权域名和支付回调域名不是同一个且后者没在商户平台里配置。解决公众号后台网页授权域名只填主域名不带路径商户平台支付授权目录填到项目根目录回调地址必须使用 HTTPS 且域名、端口与下单时完全一致。改完任一配置后最好在无痕窗口里完整走一遍进入书城、打开第一章付费页、拉起支付、支付完成回跳。只要有一步断就看微信支付商户平台里的订单记录和回调日志绝大多数问题都能从这两个入口定位到。5.4 分享链接与 session 丢失导致分销关系错乱现象读者在微信里点了别人的分享链接进入书城后看了一会儿再从公众号菜单重新进入分销关系没了。原因入口不同导致 URL 里没带 inviter 参数服务端只能认为这是无来源访问。微信 H5 里 cookie 的可用性在不同入口之间也不一致。解决把 inviter 参数通过两种通道传递一是 URL 参数进来源表二是读者首次进入时把来源写入本地存储之后从菜单进入时前端自动带出。服务端绑定关系时永远以第一次有效来源为准后续入口不覆盖。这个处理逻辑要单独写个 test 用例因为分享场景里读者来回切入口的频率非常高问题往往出现在上线后的第二天才暴露。6. 压测与对账上线后先做这两件事再放量先说压测。v1.0 会遇到的第一个量级问题不是并发下单而是并发回调。同一时刻大量支付回调涌进来如果处理脚本里没有做好幂等和快速响应微信会不断重试把数据库连接打满。我习惯先用自带的压测脚本模拟 200 并发同时打回调地址观察两个指标回调响应耗时是否稳定在 800ms 以内以及订单流水表里有没有重复入账的记录。再写一个实用的对账脚本。每天凌晨一点把微信商户平台的对账单拉下来与本地 orders 表比对筛出“微信侧已支付但本地订单未入账”和“本地入账但微信侧无记录”两类异常直接输出到运营后台提醒。// check_account.php对账脚本核心逻辑 $wechatList loadWechatBill(date(Ymd, strtotime(-1 day))); $localList getLocalPaidOrders(date(Ymd, strtotime(-1 day))); $diff []; foreach ($wechatList as $tradeNo $wxAmount) { if (!isset($localList[$tradeNo])) { $diff[wx_only][] $tradeNo; // 微信已收款本地没入账 } elseif ($localList[$tradeNo] ! $wxAmount) { $diff[amount_mismatch][] $tradeNo; // 金额不一致 } } foreach ($localList as $tradeNo $localAmount) { if (!isset($wechatList[$tradeNo])) { $diff[local_only][] $tradeNo; // 本地入账了微信对账单找不到 } } // 输出差异列表并通过企业微信机器人推送 pushAlert(json_encode($diff));对账脚本的关键是比对维度要对齐微信对账单里的金额单位是分本地订单表如果存的是元必须先转成同一单位再比较。wx_only 和 local_only 两类异常要分别处理wx_only 通常是回调延迟或回调失败脚本里可以自动触发一次查单补偿local_only 则多半是测试单或数据误操作需要人工确认后再逆操作。金额不一致的情况优先查退款微信对账单里退款金额是单独字段直接和订单金额相加再比较。我自己的习惯是压测放在上线当天对账脚本放在隔天凌晨跑第一周每天人工确认对账结果。等连续五天差异数为零了再把对账频率降为每周一次。这套流程跑顺之后分销分佣系统才敢真正放量推广。希望帮到你如果后面遇到具体问题从订单、流水、账单三层逐级往下查基本都能快速定位。本文还有配套的精品资源点击获取