尧图网页设计 
简介这是一套微信小程序淘宝客类项目源码版本1.9.8面向想快速搭建省钱赚钱应用或深入学习小程序开发的开发者与创业者。源码包含完整的前端页面、业务逻辑和资源配置压缩包内设first_duoduoke与wxapp两个模块前者实现淘宝客推广、商品信息获取及佣金计算后者承载小程序通用框架、公共组件与基础工具类。整个压缩包共595个文件以js、wxml、wxss等小程序前端代码为主体配合png、jpg等视觉素材和json配置文件另有少量html、php文件用于后台支撑包体约22.78MB目录划分清晰便于定位功能点。已有520人学习下载对刚接触微信小程序的新手而言可以借此理解WXML/WXSS布局、API调用、用户授权与数据存储等关键环节对创业者或二次开发者来说这份可直接运行的源码也提供了清晰的改造起点能够围绕界面美化、功能扩展和性能优化进行迭代。1. 首席赚钱省钱专家 1.9.8微信淘客小程序源码值不值得自己部署想做个微信小程序帮人查淘宝优惠券、顺手赚点佣金最直接的路线就是找一套淘宝客源码自己部署。「首席赚钱省钱专家 1.9.8」就是这类包里流传较广的一个版本一套 PHP 后端 微信小程序前端 管理后台覆盖商品搜索、隐藏券转链、返利发放、订单同步这些淘客小程序的标配功能。适合两类人一是有点技术底子、不想被 SaaS 平台按年抽成的个人站长二是想研究淘宝联盟 API 怎么对接、返利链路怎么设计的开发者。这篇笔记直接讲部署步骤、API 参数、以及我实际踩过的坑。2. 淘客 CPS 与返利闭环佣金从哪来用户为什么有得省2.1 先看懂成交模型隐藏券、佣金和渠道关系淘客小程序不卖货它只做一件事把用户导到淘宝下单然后凭订单拿佣金。一次典型成交分四步用户在小程序里搜到商品、看到一张比淘宝页面更低的隐藏优惠券、点复制淘口令去淘宝打开、下单后佣金进入小程序方的淘宝联盟账户。这里的关键是「隐藏券」。商家在淘宝联盟后台设置定向优惠券和佣金比例比如一件 100 元的商品设置 80 元券、佣金率 30%。用户通过淘口令领券下单实付 80 元推广方拿到 80 × 30% 24 元佣金。用户觉得省了 20 元推广方赚了佣金商家换来了销量三方各取所需。那这 24 元怎么保证是你的靠的是淘宝联盟的「渠道关系」和 PID。PID 的结构是mm_用户ID_推广位ID_渠道ID用户点了你转出来的口令淘宝就在订单上打上你这个 PID 的标记订单回流到淘宝联盟后台佣金就算到你头上。小程序里常说的「绑定关系」本质上就是把当前用户和你自己的渠道 ID 绑定确保用户在这个小程序里下的单都归你。这套 1.9.8 的源码里前后端的分工大约是这样的小程序端负责展示和交互后端负责调淘宝联盟 API 拿商品数据、生成口令、接收订单回流并计算返利。管理后台则用来配置 PID、佣金比例、提现规则。你买的不是一个小程序而是一整套「商品库 选品逻辑 订单结算系统」。2.2 返利玩法与分成算法直接返现还是积分制源码包里的返利规则一般有两种模式。一种是「直接返现金」用户下单后佣金按比例折算成余额满 1 元可提现另一种是「积分制」把返利包装成积分积分只能在小程序里换券、换实物不能直接提现。后者主要是为了过微信审核后面避坑部分我会细说。分成算法的常见写法是这样先算出商品预估佣金pub_share_pre_fee然后乘以一个后台配置的返利比例。比如后台设置用户拿 70%平台留 30%那用户实际拿到的就是预估佣金 × 0.7。需要注意这个比例不是全局统一的很多源码支持按商品类目设置——美妆类佣金高、数码类佣金低同一套规则跑下来利润差别很大。订单状态是分成里最容易算错的地方。淘宝联盟订单常见状态码有三个12 表示买家已付款13 表示确认收货3 表示交易结算。很多新手把 12 的订单直接发了返利结果用户退款佣金被淘宝追回小程序亏空。正规做法是确认收货13后发一半结算完成3后再发另一半这一点在源码里如果没做你要自己改。2.3 商品从哪来选品库、采集箱与实时搜索商品数据不是小程序自己造的而是从淘宝联盟开放平台拉。源码里一般有三种拉取方式第一种是全站选品库调taobao.tbk.dg.material.optional.upgrade按关键词/类目分页拉商品第二种是定时采集后台设置一批商品链接每天自动更新库存和券信息第三种是直接调商品详情接口用户搜什么就实时去淘宝查什么。实时搜索最灵活但最容易被限流后面第 4 章会讲频率控制怎么做。采集箱模式的好处是商品数据落地到本地数据库小程序端查商品走的是本地接口不占淘宝 API 配额。坏处是数据有时效性券可能过期所以要定时任务每小时重新采集一次。这套源码里如果你看到cron或计划任务目录就是要配定时任务的别漏了。3. 部署跑通PHP 环境、数据库导入与微信开发者工具联调3.1 环境选型PHP 7.2 起步面板方案最省事部署这类淘客源码最常见的组合是 Nginx PHP 7.2~7.4 MySQL 5.7。不建议用 PHP 8.0 以上很多老源码用了each()、create_function()这类 PHP 7 时代的方法新版本直接报致命错误。如果只有 PHP 8 环境先看报错再决定要不要降级别一上来就换。服务器我一般建议用宝塔面板不是因为它多高级而是这类源码依赖的文件权限、伪静态规则、定时任务面板上点几下就能配好。纯命令行的用户在解压和改配置上要花不少时间而且出错不容易看出来。内存给 2G 以上比较稳。小程序后端要跑定时同步订单的任务MySQL 又要存商品和订单数据1G 内存跑起来会频繁触发 swap。这个资源只给了源码服务器、域名和微信小程序账号都是你自己准备。3.2 解压与配置数据库导入和三处必改项假设你下载的压缩包里有两个主要目录后端代码目录一般含public或application文件夹和小程序前端目录常见叫miniapp或mp。先看目录结构确认后端的入口是public/index.php这种形式还是直接在根目录。后者说明不用配伪静态省一步。上传解压后做三件事建站、导库、改配置。以下是典型的初始化操作# 解压源码包假设放在 /www/wwwroot/tbk unzip shouqianzhuanjia_1.9.8.zip -d /www/wwwroot/tbk # 新建数据库并导入 SQL 文件文件名通常类似 tbk.sql 或 database.sql mysql -uroot -p -e CREATE DATABASE tbk DEFAULT CHARACTER SET utf8mb4; mysql -uroot -p tbk /www/wwwroot/tbk/tbk.sql建库时强制用 utf8mb4因为商品标题里会有表情符号和生僻字utf8 存不下。下一步的配置改三个文件就够了数据库配置、微信小程序配置、淘宝客账号配置。它们的常见路径和要改的项如下// 数据库配置常见路径 application/database.php 或 config/database.php return [ hostname 127.0.0.1, database tbk, username root, password 你的密码, prefix tbk_, // 数据库表前缀和 SQL 文件里保持一致不要改 ];数据库和表前缀能不能改表前缀可以改但改了之后所有 SQL 查询里的表名都要跟着变源码里可能用拼接方式写死了前缀所以建议保持默认。数据库密码必须改尤其是面板默认密码这类源码被扫描爆破是常态。配置文件改完后进管理后台找到「系统设置」把淘宝联盟的 app_key、app_secret、PID 填进去这是后面第 4 章的核心。另外要做的还有后台路径和默认账号。很多源码后台默认地址是/admin管理员默认admin/admin123这种弱口令。上线第一件事就是改掉不然后台就是敞开的门。3.3 微信开发者工具联调合法域名与本地调试后端跑起来后用微信开发者工具导入小程序前端目录。导入前把AppID换成你自己申请的不要用测试号因为测试号不能调 request 域名。接着改前端配置里的接口地址。// 小程序端配置文件常见路径 utils/config.js 或 app.js module.exports { // 后端接口地址必须是 https不能是 http baseUrl: https://yourdomain.com/index.php?s, // 从管理后台复制过来的版本号接口签名要用 apiVersion: v1, }接口地址我遇到很多人配错。baseUrl要配到后端入口地址不是首页地址。如果你后端入口是index.php那baseUrl就带index.php后面拼接口名才拼得上。本地联调时在微信开发者工具右上角「详情」-「本地设置」里勾选「不校验合法域名、TLS 版本以及 HTTPS 证书」这样开发阶段能访问本地接口。但真机预览或上线前必须在微信公众平台后台的「开发管理」-「服务器域名」里配置 request 合法域名。域名必须是已备案的、且是 HTTPS证书不能是自签的微信会校验证书链。前端跑通后在开发者工具里随便搜一个商品看能不能正常返回数据列表。如果报授权错误、接口不存在、签名失败基本都是后台配置没同步或者接口地址拼接有问题。这个地方不要反复动前端代码先看 network 面板里请求的实际 URL 是什么。4. 淘宝联盟 API 对接AppKey、签名计算与订单回流4.1 开放平台权限清单应用创建与接口申请去淘宝联盟开放平台属阿里妈妈体系用淘宝账号登录进入「我是开发者的-应用管理」创建一个自用型应用。注意这里不是淘宝开放平台两个平台 AppKey 不通用。很多人把 AppKey 填成淘宝开放平台的后台就会一直报签名错误或无效 key。应用创建后处于「开发中」状态此时只能调部分沙箱接口无法正式调用。要在「权限管理」里逐个申请接口权限常用接口我整理如下接口名用途申请难度taobao.tbk.dg.material.optional.upgrade商品搜索关键词拉取商品列表通常秒过taobao.tbk.item.info.get单个商品详情通常秒过taobao.tbk.tpwd.create生成淘口令略严需要说明用途taobao.tbk.order.details.get订单回流查询需要通过审核taobao.tbk.relation.refund退款订单查询需要高级权限权限申请时有个细节接口申请理由要写「自用站点推广」不要写「开发第三方应用给别人用」后者会被要求提供更复杂的资质。权限审核通过后应用状态变成「已上线」AppKey 才能真正调通。这个等待时间快则几分钟慢则一个工作日急不来。PID 在「推广管理-推广位管理」里创建一个应用下面可以建多个推广位。小程序后端配置时一般只需要一个默认 PID但如果你要做渠道区分比如区分不同推广员的订单就要为每个推广员创建独立渠道 ID这在后面第 6 章会讲。4.2 参数签名与请求一个最小可用的 PHP 样例淘宝联盟的 API 签名算法是 TOP 协议把除sign外的所有参数按 key 的字母顺序排序拼接成keyvaluekeyvalue的形式再在这个字符串前后各拼上你的app_secret做 MD5转大写。?php // 生成淘宝联盟 API 签名并发送请求 function tbkRequest($method, $bizParams, $appKey, $appSecret) { $sysParams [ method $method, app_key $appKey, timestamp date(Y-m-d H:i:s), format json, v 2.0, sign_method md5, ]; $allParams array_merge($sysParams, $bizParams); ksort($allParams); // 拼成 k1v1k2v2 并且过滤空值 $str ; foreach ($allParams as $k $v) { if ($v ! $v ! null) { $str . $k . $v; } } $allParams[sign] strtoupper(md5($appSecret . $str . $appSecret)); // 发起 HTTP 请求网关地址固定 $ch curl_init(https://eco.taobao.com/router/rest); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($allParams)); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_TIMEOUT, 10); $response curl_exec($ch); curl_close($ch); return json_decode($response, true); }签名拼接时要特别注意空的业务参数不参与签名timestamp的格式是YYYY-MM-dd HH:mm:ss不是时间戳用错格式签名永远对不上。method参数本身参与签名但要放在sysParams里一起拼很多人只给业务参数签名结果报sign check fail。请求一个商品详情的示例?php $biz [ num_iids 商品ID, adzone_id 你后台配置的推广位ID, relation_id 渠道ID没有可传空, ]; $result tbkRequest(taobao.tbk.item.info.get, $biz, $appKey, $appSecret);放在定时任务里跑时建议加一个异常重试返回为空或报错时记录日志并等 5 秒重试不要死循环。淘宝联盟接口正常响应里如果带sub_msg和sub_code那就是业务层面的错误提示比如「推广位不存在」「商品已下架」。4.3 订单回流与返利发放tk_status 的三种判定订单同步是返利小程序最核心的环节。用户下单后淘宝联盟不会立刻把订单推给你需要你主动去拉。源码里一般有一个定时任务每隔 30 到 60 分钟调用一次taobao.tbk.order.details.get把最近几小时的订单拉到本地库。拉取时务必使用分页和时间窗口。淘宝的订单查询接口返回有上限一般单次最多 100 条时间窗口最长也只能查最近 24 小时。代码里常见的做法是每小时跑一次查询start_time到end_time之间的订单然后按trade_id去重入库。订单回流的判断逻辑我在实际项目里是这样写的?php // 订单回流处理伪代码 if ($order[tk_status] 3) { // 已结算佣金已到账可以给用户发全款返利 $refundAmount $order[pub_share_pre_fee] * $order[income_rate] / 100; } elseif ($order[tk_status] 13) { // 已确认收货还没结算发一半返利等结算后再补 $refundAmount $order[pub_share_pre_fee] * $order[income_rate] / 100 * 0.5; } else { // 状态 12 付款未确认收货标记为待确认不发返利 continue; }pub_share_pre_fee是预估佣金income_rate是佣金比率tk_status是订单状态。很多源码只判断了等于 3 的情况等于 13 的订单没处理用户等得不耐烦就去退款导致本来能结算的订单也退了。我一般会再加一层订单入库后先不发返利等结算状态确认后才进入余额确认收货但未结算的给用户一个「已确认」标识让他看到订单有进展但不真的打钱。退款单的处理同样关键。taobao.tbk.relation.refund会返回退款订单列表拉回来后要把本地订单表的返利状态置为「已扣回」并把用户余额里已发放的返利扣掉。如果源码没做扣回逻辑那退款订单产生的亏损只能自己扛佣金还没到手就发出去了这是返利小程序最严重的资金漏洞。5. 避坑笔记审核被拒、佣金丢失与源码后门排查5.1 小程序审核被拒返现文案和分销页面是重灾区现象提交微信审核提示「涉及返利有风险」或「页面包含诱导分享内容」直接被驳回。常见于页面上写了「返现」「提现」「赚佣金」这类字眼或者带有「我的团队」「三级返佣」页面。原因微信对返利、分销类小程序管控非常严。个人主体根本不能过企业主体也需要选择合适的类目。即便类目选对页面文案里有「现金返利」相关字样审核也会判定为高风险。解决把「返现」统一改成「福利金」「积分」提现按钮改成「兑换」或「客服处理」。二级分销页面干脆删掉不要留任何多级返佣的逻辑和入口。小程序名称里也别带「赚钱」「省钱」这类字眼命名成「某某好物」「某某优惠」更稳。类目方面企业主体选「商家自营-百货」或「电商平台-在线销售平台」后者资质要求更高选前者能省不少事。5.2 佣金对不上十有八九是关系绑定和订单类型现象后台看到订单回流了但佣金是 0或者某几个用户的订单始终不算到小程序头上。原因第一用户没走你生成的淘口令而是自己另外在淘宝里找同款下单订单归属是别人的 PID第二用户领了别人的隐藏券订单被淘宝判定归属到券的发布者第三订单类型是虚拟商品或者不参与 CPS 推广的商品本身就是 0 佣金。解决在小程序端强制处理分享链路用户点击「复制口令」时后端要让这条口令绑定当前推广员的relation_id口令里带上推广位信息。用户在淘宝里复购时如果先点了别的口令那单子大概率会丢。佣金为 0 的订单做好过滤在订单列表里标记原因不要给用户展示成「小编微信」让人家来问。这类订单查询接口返回的tk_status和alimama_share_fee字段分别对应状态和实际佣金0 佣金时别发放即可。5.3 源码包自带后门上线前的安全检查不能跳过现象网站跑了一周发现数据库被清空、或者被植入赌博广告、或者后台莫名其妙多了一个管理员账号。这类源码包是最容易被动手脚的地方。原因打包分享的 PHP 源码里经常藏着加密的后门文件常见的藏在/Public/、/uploads/、/include/目录里文件名伪装成logo.php、cache.php这类看似正常的文件。代码可能用base64_decode gzinflate eval组合执行远程下载的内容或者直接file_put_contents种木马。解决解压后用find找最近修改的 PHP 文件优先检查可疑内容# 查找最近 3 天修改过的 PHP 文件后门一般就在其中 find /www/wwwroot/tbk -name *.php -mtime -3 # 搜索高危函数调用 grep -rn eval( /www/wwwroot/tbk --include*.php grep -rn base64_decode /www/wwwroot/tbk --include*.php grep -rn gzinflate /www/wwwroot/tbk --include*.php搜到的文件逐个打开看正常业务代码里出现base64_decode且编码串长得不像普通配置的直接删掉或改名。改名不是根治如果你不确定是否干净最稳妥的做法是只保留数据库配置文件用官方渠道重新下载源码覆盖一遍。管理员密码和后台路径必须立即改数据库连接用户要做到最小权限不要给root全程走外网连接。从那次之后我养成了习惯任何第三方 PHP 源码上线前先把这四条命令跑一遍。5.4 请求全部失败先查合法域名、证书和入口地址现象小程序端请求接口全部报「不在以下 request 合法域名列表中」或者报「网络错误」、HTTP 状态 500、502。原因最常见的是三个地方同时出错——微信后台没配 request 合法域名、HTTPS 证书是自签的、后端根本没部署在同域名下。还有一个隐蔽原因后端接口需要带s参数走路由你配置的baseUrl没带全导致请求到了首页而非 API 入口。解决先用浏览器直接访问https://你的域名/index.php?s接口路由确认返回 JSON 而非 HTML。然后在微信公众平台「开发管理-服务器域名」里把https://你的域名加进 request 合法域名。证书方面用 Lets Encrypt 签的免费证书就行但一定要开启自动续期。开发者工具里勾选不校验合法域名只对本地联调有用真机预览必须走正式域名。502 问题基本出在 PHP-FPM 进程没起来或超时看nginx_error.log定位。5.5 定时任务配置后不执行权限和路径都在指向不存在现象订单同步功能开启后后台一直显示「最后同步时间」是几天前或者永远停在初始状态。原因定时任务没执行。源码里大多让你在宝塔的「计划任务」里写一条curl --silent https://你的域名/index.php?s/cron/run但很多人用wget直接访问 URL服务器上没装 wget命令静默失败或者宝塔计划任务的执行权限和 PHP-FPM 运行用户不一致缓存目录写不进去。解决统一用 curl 并写完整路径任务周期设成每 10 分钟一次最低粒度。调试时先手动在浏览器执行一次同步 URL确认订单能拉回来再去宝塔配置计划任务。注意记录日志在任务命令里加 /www/wwwroot/tbk/cron.log 21下次看日志就知道卡在哪个环节。权限问题则去站点目录把runtime缓存目录设置为 755 并确保属主是www。6. 口令生成做幂等把分享转化和 API 配额一起保住6.1 同一商品同一渠道半小时内只调一次生成接口淘口令生成接口taobao.tbk.tpwd.create有频率限制同一个 AppKey 每秒调用次数不允许太高同时淘宝风控会识别「批量生成相同口令」的异常行为。小程序里最常见的场景是用户反复点击「复制口令」按钮每次点击都调一次生成接口不仅浪费配额还容易被风控限掉账号。解决思路是加一层缓存用商品 ID 和渠道 ID 组合作为 key。同一个推广员分享同一个商品短时间内复用同一条口令即可?php // 生成口令前先查缓存命中就直接返回不再调淘宝接口 function getTpwd($itemId, $relationId) { $cacheKey tpwd:{$itemId}:{$relationId}; $cached Redis::get($cacheKey); if ($cached) { return $cached; } $tpwd TbkApi::createTpwd($itemId, $relationId); // 实际调淘宝联盟接口 Redis::setex($cacheKey, 1800, $tpwd); // 半小时内复用 return $tpwd; }时间设成半小时比较合理太长会导致口令对应的券过期太短又起不到压频控的作用。注意缓存 key 里要带relationId不同推广员分享同一个商品生成的口令归属必须不同不能全局共用一条。生成失败时不要缓存空值否则会导致半小时内所有用户拿不到口令。6.2 商品详情接口的缓存策略页面加载别直接穿透到淘宝小程序首页和搜索结果是流量最高的页面每个商品卡片都要显示券后价、月销量、佣金金额。如果这些数据都实时去淘宝拉一是页面慢二是一旦用户量上来AppKey 的配额消耗极快眼睁睁看着报「频控超限」但用户那边只是觉得卡。商品详情的缓存要比口令缓存更厚一点。以商品 ID 为 key缓存整个商品数据 JSON时间设一小时到一个半小时。超过时间后标记过期下一次访问时再更新?php // 商品详情缓存过期后主动刷新而不是每次都打淘宝接口 function getItemWithCache($itemId) { $key item:detail:{$itemId}; $data Redis::get($key); if ($data) { return json_decode($data, true); } $data TbkApi::getItemDetail($itemId); if (!empty($data[result])) { Redis::setex($key, 3600, json_encode($data, JSON_UNESCAPED_UNICODE)); } return $data; }这里有一个很重要的细节缓存失效后用户刷到同一批商品时后面每个请求都可能触发一次重新拉取瞬间打满配额。我一般会加一个「锁」确保同一时刻同一个商品只有一个进程去刷新缓存其他进程继续用旧数据甚至直接返回延迟更新。真实场景里只要你把一个商品的更新控制在 1 分钟 1 次就足以扛住几千人的同时访问。从那以后我每次部署淘客源码强制自己先做两件事检查后门文件、给商品详情和口令生成加缓存。前者避免被黑后者避免上线当天 API 配额就烧完。这套检查流程现在不管部署哪个版本都会走一遍。希望帮到你。本文还有配套的精品资源点击获取 微信淘客小程序源码部署与淘宝联盟API对接实战
简介这是一套微信小程序淘宝客类项目源码版本1.9.8面向想快速搭建省钱赚钱应用或深入学习小程序开发的开发者与创业者。源码包含完整的前端页面、业务逻辑和资源配置压缩包内设first_duoduoke与wxapp两个模块前者实现淘宝客推广、商品信息获取及佣金计算后者承载小程序通用框架、公共组件与基础工具类。整个压缩包共595个文件以js、wxml、wxss等小程序前端代码为主体配合png、jpg等视觉素材和json配置文件另有少量html、php文件用于后台支撑包体约22.78MB目录划分清晰便于定位功能点。已有520人学习下载对刚接触微信小程序的新手而言可以借此理解WXML/WXSS布局、API调用、用户授权与数据存储等关键环节对创业者或二次开发者来说这份可直接运行的源码也提供了清晰的改造起点能够围绕界面美化、功能扩展和性能优化进行迭代。1. 首席赚钱省钱专家 1.9.8微信淘客小程序源码值不值得自己部署想做个微信小程序帮人查淘宝优惠券、顺手赚点佣金最直接的路线就是找一套淘宝客源码自己部署。「首席赚钱省钱专家 1.9.8」就是这类包里流传较广的一个版本一套 PHP 后端 微信小程序前端 管理后台覆盖商品搜索、隐藏券转链、返利发放、订单同步这些淘客小程序的标配功能。适合两类人一是有点技术底子、不想被 SaaS 平台按年抽成的个人站长二是想研究淘宝联盟 API 怎么对接、返利链路怎么设计的开发者。这篇笔记直接讲部署步骤、API 参数、以及我实际踩过的坑。2. 淘客 CPS 与返利闭环佣金从哪来用户为什么有得省2.1 先看懂成交模型隐藏券、佣金和渠道关系淘客小程序不卖货它只做一件事把用户导到淘宝下单然后凭订单拿佣金。一次典型成交分四步用户在小程序里搜到商品、看到一张比淘宝页面更低的隐藏优惠券、点复制淘口令去淘宝打开、下单后佣金进入小程序方的淘宝联盟账户。这里的关键是「隐藏券」。商家在淘宝联盟后台设置定向优惠券和佣金比例比如一件 100 元的商品设置 80 元券、佣金率 30%。用户通过淘口令领券下单实付 80 元推广方拿到 80 × 30% 24 元佣金。用户觉得省了 20 元推广方赚了佣金商家换来了销量三方各取所需。那这 24 元怎么保证是你的靠的是淘宝联盟的「渠道关系」和 PID。PID 的结构是mm_用户ID_推广位ID_渠道ID用户点了你转出来的口令淘宝就在订单上打上你这个 PID 的标记订单回流到淘宝联盟后台佣金就算到你头上。小程序里常说的「绑定关系」本质上就是把当前用户和你自己的渠道 ID 绑定确保用户在这个小程序里下的单都归你。这套 1.9.8 的源码里前后端的分工大约是这样的小程序端负责展示和交互后端负责调淘宝联盟 API 拿商品数据、生成口令、接收订单回流并计算返利。管理后台则用来配置 PID、佣金比例、提现规则。你买的不是一个小程序而是一整套「商品库 选品逻辑 订单结算系统」。2.2 返利玩法与分成算法直接返现还是积分制源码包里的返利规则一般有两种模式。一种是「直接返现金」用户下单后佣金按比例折算成余额满 1 元可提现另一种是「积分制」把返利包装成积分积分只能在小程序里换券、换实物不能直接提现。后者主要是为了过微信审核后面避坑部分我会细说。分成算法的常见写法是这样先算出商品预估佣金pub_share_pre_fee然后乘以一个后台配置的返利比例。比如后台设置用户拿 70%平台留 30%那用户实际拿到的就是预估佣金 × 0.7。需要注意这个比例不是全局统一的很多源码支持按商品类目设置——美妆类佣金高、数码类佣金低同一套规则跑下来利润差别很大。订单状态是分成里最容易算错的地方。淘宝联盟订单常见状态码有三个12 表示买家已付款13 表示确认收货3 表示交易结算。很多新手把 12 的订单直接发了返利结果用户退款佣金被淘宝追回小程序亏空。正规做法是确认收货13后发一半结算完成3后再发另一半这一点在源码里如果没做你要自己改。2.3 商品从哪来选品库、采集箱与实时搜索商品数据不是小程序自己造的而是从淘宝联盟开放平台拉。源码里一般有三种拉取方式第一种是全站选品库调taobao.tbk.dg.material.optional.upgrade按关键词/类目分页拉商品第二种是定时采集后台设置一批商品链接每天自动更新库存和券信息第三种是直接调商品详情接口用户搜什么就实时去淘宝查什么。实时搜索最灵活但最容易被限流后面第 4 章会讲频率控制怎么做。采集箱模式的好处是商品数据落地到本地数据库小程序端查商品走的是本地接口不占淘宝 API 配额。坏处是数据有时效性券可能过期所以要定时任务每小时重新采集一次。这套源码里如果你看到cron或计划任务目录就是要配定时任务的别漏了。3. 部署跑通PHP 环境、数据库导入与微信开发者工具联调3.1 环境选型PHP 7.2 起步面板方案最省事部署这类淘客源码最常见的组合是 Nginx PHP 7.2~7.4 MySQL 5.7。不建议用 PHP 8.0 以上很多老源码用了each()、create_function()这类 PHP 7 时代的方法新版本直接报致命错误。如果只有 PHP 8 环境先看报错再决定要不要降级别一上来就换。服务器我一般建议用宝塔面板不是因为它多高级而是这类源码依赖的文件权限、伪静态规则、定时任务面板上点几下就能配好。纯命令行的用户在解压和改配置上要花不少时间而且出错不容易看出来。内存给 2G 以上比较稳。小程序后端要跑定时同步订单的任务MySQL 又要存商品和订单数据1G 内存跑起来会频繁触发 swap。这个资源只给了源码服务器、域名和微信小程序账号都是你自己准备。3.2 解压与配置数据库导入和三处必改项假设你下载的压缩包里有两个主要目录后端代码目录一般含public或application文件夹和小程序前端目录常见叫miniapp或mp。先看目录结构确认后端的入口是public/index.php这种形式还是直接在根目录。后者说明不用配伪静态省一步。上传解压后做三件事建站、导库、改配置。以下是典型的初始化操作# 解压源码包假设放在 /www/wwwroot/tbk unzip shouqianzhuanjia_1.9.8.zip -d /www/wwwroot/tbk # 新建数据库并导入 SQL 文件文件名通常类似 tbk.sql 或 database.sql mysql -uroot -p -e CREATE DATABASE tbk DEFAULT CHARACTER SET utf8mb4; mysql -uroot -p tbk /www/wwwroot/tbk/tbk.sql建库时强制用 utf8mb4因为商品标题里会有表情符号和生僻字utf8 存不下。下一步的配置改三个文件就够了数据库配置、微信小程序配置、淘宝客账号配置。它们的常见路径和要改的项如下// 数据库配置常见路径 application/database.php 或 config/database.php return [ hostname 127.0.0.1, database tbk, username root, password 你的密码, prefix tbk_, // 数据库表前缀和 SQL 文件里保持一致不要改 ];数据库和表前缀能不能改表前缀可以改但改了之后所有 SQL 查询里的表名都要跟着变源码里可能用拼接方式写死了前缀所以建议保持默认。数据库密码必须改尤其是面板默认密码这类源码被扫描爆破是常态。配置文件改完后进管理后台找到「系统设置」把淘宝联盟的 app_key、app_secret、PID 填进去这是后面第 4 章的核心。另外要做的还有后台路径和默认账号。很多源码后台默认地址是/admin管理员默认admin/admin123这种弱口令。上线第一件事就是改掉不然后台就是敞开的门。3.3 微信开发者工具联调合法域名与本地调试后端跑起来后用微信开发者工具导入小程序前端目录。导入前把AppID换成你自己申请的不要用测试号因为测试号不能调 request 域名。接着改前端配置里的接口地址。// 小程序端配置文件常见路径 utils/config.js 或 app.js module.exports { // 后端接口地址必须是 https不能是 http baseUrl: https://yourdomain.com/index.php?s, // 从管理后台复制过来的版本号接口签名要用 apiVersion: v1, }接口地址我遇到很多人配错。baseUrl要配到后端入口地址不是首页地址。如果你后端入口是index.php那baseUrl就带index.php后面拼接口名才拼得上。本地联调时在微信开发者工具右上角「详情」-「本地设置」里勾选「不校验合法域名、TLS 版本以及 HTTPS 证书」这样开发阶段能访问本地接口。但真机预览或上线前必须在微信公众平台后台的「开发管理」-「服务器域名」里配置 request 合法域名。域名必须是已备案的、且是 HTTPS证书不能是自签的微信会校验证书链。前端跑通后在开发者工具里随便搜一个商品看能不能正常返回数据列表。如果报授权错误、接口不存在、签名失败基本都是后台配置没同步或者接口地址拼接有问题。这个地方不要反复动前端代码先看 network 面板里请求的实际 URL 是什么。4. 淘宝联盟 API 对接AppKey、签名计算与订单回流4.1 开放平台权限清单应用创建与接口申请去淘宝联盟开放平台属阿里妈妈体系用淘宝账号登录进入「我是开发者的-应用管理」创建一个自用型应用。注意这里不是淘宝开放平台两个平台 AppKey 不通用。很多人把 AppKey 填成淘宝开放平台的后台就会一直报签名错误或无效 key。应用创建后处于「开发中」状态此时只能调部分沙箱接口无法正式调用。要在「权限管理」里逐个申请接口权限常用接口我整理如下接口名用途申请难度taobao.tbk.dg.material.optional.upgrade商品搜索关键词拉取商品列表通常秒过taobao.tbk.item.info.get单个商品详情通常秒过taobao.tbk.tpwd.create生成淘口令略严需要说明用途taobao.tbk.order.details.get订单回流查询需要通过审核taobao.tbk.relation.refund退款订单查询需要高级权限权限申请时有个细节接口申请理由要写「自用站点推广」不要写「开发第三方应用给别人用」后者会被要求提供更复杂的资质。权限审核通过后应用状态变成「已上线」AppKey 才能真正调通。这个等待时间快则几分钟慢则一个工作日急不来。PID 在「推广管理-推广位管理」里创建一个应用下面可以建多个推广位。小程序后端配置时一般只需要一个默认 PID但如果你要做渠道区分比如区分不同推广员的订单就要为每个推广员创建独立渠道 ID这在后面第 6 章会讲。4.2 参数签名与请求一个最小可用的 PHP 样例淘宝联盟的 API 签名算法是 TOP 协议把除sign外的所有参数按 key 的字母顺序排序拼接成keyvaluekeyvalue的形式再在这个字符串前后各拼上你的app_secret做 MD5转大写。?php // 生成淘宝联盟 API 签名并发送请求 function tbkRequest($method, $bizParams, $appKey, $appSecret) { $sysParams [ method $method, app_key $appKey, timestamp date(Y-m-d H:i:s), format json, v 2.0, sign_method md5, ]; $allParams array_merge($sysParams, $bizParams); ksort($allParams); // 拼成 k1v1k2v2 并且过滤空值 $str ; foreach ($allParams as $k $v) { if ($v ! $v ! null) { $str . $k . $v; } } $allParams[sign] strtoupper(md5($appSecret . $str . $appSecret)); // 发起 HTTP 请求网关地址固定 $ch curl_init(https://eco.taobao.com/router/rest); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($allParams)); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_TIMEOUT, 10); $response curl_exec($ch); curl_close($ch); return json_decode($response, true); }签名拼接时要特别注意空的业务参数不参与签名timestamp的格式是YYYY-MM-dd HH:mm:ss不是时间戳用错格式签名永远对不上。method参数本身参与签名但要放在sysParams里一起拼很多人只给业务参数签名结果报sign check fail。请求一个商品详情的示例?php $biz [ num_iids 商品ID, adzone_id 你后台配置的推广位ID, relation_id 渠道ID没有可传空, ]; $result tbkRequest(taobao.tbk.item.info.get, $biz, $appKey, $appSecret);放在定时任务里跑时建议加一个异常重试返回为空或报错时记录日志并等 5 秒重试不要死循环。淘宝联盟接口正常响应里如果带sub_msg和sub_code那就是业务层面的错误提示比如「推广位不存在」「商品已下架」。4.3 订单回流与返利发放tk_status 的三种判定订单同步是返利小程序最核心的环节。用户下单后淘宝联盟不会立刻把订单推给你需要你主动去拉。源码里一般有一个定时任务每隔 30 到 60 分钟调用一次taobao.tbk.order.details.get把最近几小时的订单拉到本地库。拉取时务必使用分页和时间窗口。淘宝的订单查询接口返回有上限一般单次最多 100 条时间窗口最长也只能查最近 24 小时。代码里常见的做法是每小时跑一次查询start_time到end_time之间的订单然后按trade_id去重入库。订单回流的判断逻辑我在实际项目里是这样写的?php // 订单回流处理伪代码 if ($order[tk_status] 3) { // 已结算佣金已到账可以给用户发全款返利 $refundAmount $order[pub_share_pre_fee] * $order[income_rate] / 100; } elseif ($order[tk_status] 13) { // 已确认收货还没结算发一半返利等结算后再补 $refundAmount $order[pub_share_pre_fee] * $order[income_rate] / 100 * 0.5; } else { // 状态 12 付款未确认收货标记为待确认不发返利 continue; }pub_share_pre_fee是预估佣金income_rate是佣金比率tk_status是订单状态。很多源码只判断了等于 3 的情况等于 13 的订单没处理用户等得不耐烦就去退款导致本来能结算的订单也退了。我一般会再加一层订单入库后先不发返利等结算状态确认后才进入余额确认收货但未结算的给用户一个「已确认」标识让他看到订单有进展但不真的打钱。退款单的处理同样关键。taobao.tbk.relation.refund会返回退款订单列表拉回来后要把本地订单表的返利状态置为「已扣回」并把用户余额里已发放的返利扣掉。如果源码没做扣回逻辑那退款订单产生的亏损只能自己扛佣金还没到手就发出去了这是返利小程序最严重的资金漏洞。5. 避坑笔记审核被拒、佣金丢失与源码后门排查5.1 小程序审核被拒返现文案和分销页面是重灾区现象提交微信审核提示「涉及返利有风险」或「页面包含诱导分享内容」直接被驳回。常见于页面上写了「返现」「提现」「赚佣金」这类字眼或者带有「我的团队」「三级返佣」页面。原因微信对返利、分销类小程序管控非常严。个人主体根本不能过企业主体也需要选择合适的类目。即便类目选对页面文案里有「现金返利」相关字样审核也会判定为高风险。解决把「返现」统一改成「福利金」「积分」提现按钮改成「兑换」或「客服处理」。二级分销页面干脆删掉不要留任何多级返佣的逻辑和入口。小程序名称里也别带「赚钱」「省钱」这类字眼命名成「某某好物」「某某优惠」更稳。类目方面企业主体选「商家自营-百货」或「电商平台-在线销售平台」后者资质要求更高选前者能省不少事。5.2 佣金对不上十有八九是关系绑定和订单类型现象后台看到订单回流了但佣金是 0或者某几个用户的订单始终不算到小程序头上。原因第一用户没走你生成的淘口令而是自己另外在淘宝里找同款下单订单归属是别人的 PID第二用户领了别人的隐藏券订单被淘宝判定归属到券的发布者第三订单类型是虚拟商品或者不参与 CPS 推广的商品本身就是 0 佣金。解决在小程序端强制处理分享链路用户点击「复制口令」时后端要让这条口令绑定当前推广员的relation_id口令里带上推广位信息。用户在淘宝里复购时如果先点了别的口令那单子大概率会丢。佣金为 0 的订单做好过滤在订单列表里标记原因不要给用户展示成「小编微信」让人家来问。这类订单查询接口返回的tk_status和alimama_share_fee字段分别对应状态和实际佣金0 佣金时别发放即可。5.3 源码包自带后门上线前的安全检查不能跳过现象网站跑了一周发现数据库被清空、或者被植入赌博广告、或者后台莫名其妙多了一个管理员账号。这类源码包是最容易被动手脚的地方。原因打包分享的 PHP 源码里经常藏着加密的后门文件常见的藏在/Public/、/uploads/、/include/目录里文件名伪装成logo.php、cache.php这类看似正常的文件。代码可能用base64_decode gzinflate eval组合执行远程下载的内容或者直接file_put_contents种木马。解决解压后用find找最近修改的 PHP 文件优先检查可疑内容# 查找最近 3 天修改过的 PHP 文件后门一般就在其中 find /www/wwwroot/tbk -name *.php -mtime -3 # 搜索高危函数调用 grep -rn eval( /www/wwwroot/tbk --include*.php grep -rn base64_decode /www/wwwroot/tbk --include*.php grep -rn gzinflate /www/wwwroot/tbk --include*.php搜到的文件逐个打开看正常业务代码里出现base64_decode且编码串长得不像普通配置的直接删掉或改名。改名不是根治如果你不确定是否干净最稳妥的做法是只保留数据库配置文件用官方渠道重新下载源码覆盖一遍。管理员密码和后台路径必须立即改数据库连接用户要做到最小权限不要给root全程走外网连接。从那次之后我养成了习惯任何第三方 PHP 源码上线前先把这四条命令跑一遍。5.4 请求全部失败先查合法域名、证书和入口地址现象小程序端请求接口全部报「不在以下 request 合法域名列表中」或者报「网络错误」、HTTP 状态 500、502。原因最常见的是三个地方同时出错——微信后台没配 request 合法域名、HTTPS 证书是自签的、后端根本没部署在同域名下。还有一个隐蔽原因后端接口需要带s参数走路由你配置的baseUrl没带全导致请求到了首页而非 API 入口。解决先用浏览器直接访问https://你的域名/index.php?s接口路由确认返回 JSON 而非 HTML。然后在微信公众平台「开发管理-服务器域名」里把https://你的域名加进 request 合法域名。证书方面用 Lets Encrypt 签的免费证书就行但一定要开启自动续期。开发者工具里勾选不校验合法域名只对本地联调有用真机预览必须走正式域名。502 问题基本出在 PHP-FPM 进程没起来或超时看nginx_error.log定位。5.5 定时任务配置后不执行权限和路径都在指向不存在现象订单同步功能开启后后台一直显示「最后同步时间」是几天前或者永远停在初始状态。原因定时任务没执行。源码里大多让你在宝塔的「计划任务」里写一条curl --silent https://你的域名/index.php?s/cron/run但很多人用wget直接访问 URL服务器上没装 wget命令静默失败或者宝塔计划任务的执行权限和 PHP-FPM 运行用户不一致缓存目录写不进去。解决统一用 curl 并写完整路径任务周期设成每 10 分钟一次最低粒度。调试时先手动在浏览器执行一次同步 URL确认订单能拉回来再去宝塔配置计划任务。注意记录日志在任务命令里加 /www/wwwroot/tbk/cron.log 21下次看日志就知道卡在哪个环节。权限问题则去站点目录把runtime缓存目录设置为 755 并确保属主是www。6. 口令生成做幂等把分享转化和 API 配额一起保住6.1 同一商品同一渠道半小时内只调一次生成接口淘口令生成接口taobao.tbk.tpwd.create有频率限制同一个 AppKey 每秒调用次数不允许太高同时淘宝风控会识别「批量生成相同口令」的异常行为。小程序里最常见的场景是用户反复点击「复制口令」按钮每次点击都调一次生成接口不仅浪费配额还容易被风控限掉账号。解决思路是加一层缓存用商品 ID 和渠道 ID 组合作为 key。同一个推广员分享同一个商品短时间内复用同一条口令即可?php // 生成口令前先查缓存命中就直接返回不再调淘宝接口 function getTpwd($itemId, $relationId) { $cacheKey tpwd:{$itemId}:{$relationId}; $cached Redis::get($cacheKey); if ($cached) { return $cached; } $tpwd TbkApi::createTpwd($itemId, $relationId); // 实际调淘宝联盟接口 Redis::setex($cacheKey, 1800, $tpwd); // 半小时内复用 return $tpwd; }时间设成半小时比较合理太长会导致口令对应的券过期太短又起不到压频控的作用。注意缓存 key 里要带relationId不同推广员分享同一个商品生成的口令归属必须不同不能全局共用一条。生成失败时不要缓存空值否则会导致半小时内所有用户拿不到口令。6.2 商品详情接口的缓存策略页面加载别直接穿透到淘宝小程序首页和搜索结果是流量最高的页面每个商品卡片都要显示券后价、月销量、佣金金额。如果这些数据都实时去淘宝拉一是页面慢二是一旦用户量上来AppKey 的配额消耗极快眼睁睁看着报「频控超限」但用户那边只是觉得卡。商品详情的缓存要比口令缓存更厚一点。以商品 ID 为 key缓存整个商品数据 JSON时间设一小时到一个半小时。超过时间后标记过期下一次访问时再更新?php // 商品详情缓存过期后主动刷新而不是每次都打淘宝接口 function getItemWithCache($itemId) { $key item:detail:{$itemId}; $data Redis::get($key); if ($data) { return json_decode($data, true); } $data TbkApi::getItemDetail($itemId); if (!empty($data[result])) { Redis::setex($key, 3600, json_encode($data, JSON_UNESCAPED_UNICODE)); } return $data; }这里有一个很重要的细节缓存失效后用户刷到同一批商品时后面每个请求都可能触发一次重新拉取瞬间打满配额。我一般会加一个「锁」确保同一时刻同一个商品只有一个进程去刷新缓存其他进程继续用旧数据甚至直接返回延迟更新。真实场景里只要你把一个商品的更新控制在 1 分钟 1 次就足以扛住几千人的同时访问。从那以后我每次部署淘客源码强制自己先做两件事检查后门文件、给商品详情和口令生成加缓存。前者避免被黑后者避免上线当天 API 配额就烧完。这套检查流程现在不管部署哪个版本都会走一遍。希望帮到你。本文还有配套的精品资源点击获取