简介：这是一套面向拼多多优惠购物场景的微信小程序完整源码项目，版本为v1.9.80+，适合小程序开发者、电商运营者或希望搭建返利分销平台的个人站长学习与二次开发。资源共1347个文件，压缩包约31.48MB，文件类型涵盖小程序前端WXML/WXSS/JS页面、PHP后端接口、JSON配置、PNG/JPG图片素材、HTML管理后台页面，以及DAT数据文件、GIF动图、TTF字体、MP3提示音等辅助资源。其中前端源码负责界面展示与交互，PHP接口提供数据支撑，JSON配置用于参数管理，图片素材用于界面美化，整体具备完整可运行的前后端项目结构。核心功能方面，项目对接拼多多官方接口，能够展示每日优惠商品并直接标示每件商品的优惠力度与返利收入；用户购物后可获得返利，也可通过邀请好友组建团队，下级消费时上级可获得相应奖励。后台支持自定义分润比例，用户提现全程自动完成，无需人工干预，可显著降低运营成本。目前已有419人学习下载，适合深入研究社交电商小程序的分销返利机制、PHP接口开发思路、小程序端与后端协同方式以及完整业务流程的代码组织，是一份实用的实战参考资料。
1. 省钱赚钱客户端小程序，复杂度不在页面而在状态闭环
「首席赚钱省钱专家」把产品切成两块：赚钱对应返利与任务，省钱对应券与比价。两块业务在服务端各做各的，在客户端小程序里却共用一套页面容器、登录态和数据通道，真正的复杂度在领券、下单、回跳闭环里客户端自己扛的分发与状态管理。
v1.9.80 说明它迭代过多轮：主包分包怎么拆、缓存怎么失效、金额精度怎么约定，都是客户端要背的账。这类产品长在微信里，群里点开、立即领券、拉起下单，不应该让用户想起还要装一个 App。
客户端小程序既要保首屏，又要在分享页、落地页、支付回跳之间维持一致的登录态与优惠态。下面按形态选型、模块拆分、数据组织、接口契约、上线验证这条线讲工程边界，适合正在做微信小程序电商、返利、优惠聚合的客户端开发，也适合接手存量项目后要动架构的人。
2. 省钱客户端小程序的模块边界：主包分包与跨端选型
拿到一个省钱赚钱客户端的存量工程，第一步不是读业务代码，而是先看 app.json 和构建产物。这类产品的页面数量一定远超主包容量：券列表、券详情、比价、订单、返利明细、邀请海报、签到任务页，随便一凑就是二十个页面。微信小程序主包 2MB 的硬上限摆在那里，页面拆进哪个包，直接决定首屏下载体积和分享落地页的白屏概率。
2.1 主包只留入口与授权，券与订单全部进分包
先记三条规则：tabBar 页面必须在主包；分享落地页必须在主包；其余页面能进分包就进分包。tabBar 的壳页面只做导航和占位，真正的列表由分包承接。主包只放首页、分享页、个人中心三类入口页，加上登录授权、公共组件和工具库。
分包配置在 app.json 里写，常见做法是按住域拆而不是按页面拆：pkg-coupon 装券相关，pkg-order 装订单与返利。按域拆的好处是预下载时可以整包拉取，用户从分享页进入后大概率只需要再下载一个分包。
{ "pages": ["pages/index/index", "pages/share/index", "pages/profile/index"], "subpackages": [ { "root": "pkg-coupon", "pages": ["list/index", "detail/index", "verify/index"] }, { "root": "pkg-order", "pages": ["list/index", "rebate/index", "after-sale/index"] } ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["pkg-coupon"] } } }root 是分包根目录，不能以斜杠开头，pages 里写的是相对 root 的路径。preloadRule 在用户进入首页时预下载 pkg-coupon，network 设 all 表示 wifi 与流量环境都预下载；券列表是省钱客户端的流量入口，这几十 KB 的预下载成本值得付。如果某个活动分包只在特定城市生效，就不要放 preloadRule，改成点击时调 wx.loadSubpackage 手动加载，加载期间用页面自带的 loading 态兜底。
分享落地页为什么必须在主包：从群卡片点进来，微信按 path 直接拉起页面，如果该页面在未下载的分包里，用户会先看到白屏或分包下载 loading。把 share 页放主包，页面一百毫秒内出内容，券数据再慢慢加载，首屏体感完全不同。
2.2 跨端选型对照：原生、uni-app 与 Taro
省钱类产品很少只做微信。返利与优惠聚合的流量天然分散，抖音、支付宝的小程序生态和微信差异不小，选型本质上是赌团队能把多端成本控制在哪个量级。
| 方案 | 语言 | 多端覆盖 | 调试体验 | 适合场景 |
|---|---|---|---|---|
| 原生小程序 | WXML/WXSS/JS | 仅微信 | 开发者工具最全，包体控制最好 | 只做微信、卡主包体积 |
| uni-app | Vue | 微信/支付宝/抖音/App | HBuilderX 一条链 | 返利商城类快速铺端 |
| Taro | React | 微信/支付宝/抖音/H5 | 接近 Web 工程 | 团队是 React 栈 |
选型给个个人结论：只做微信就写原生，包体能压到最小，调试链路最短；明确要多端，用 uni-app 配合 HBuilderX，因为省钱类页面主要是列表、详情、表单，Vue 语法迁移成本低。但无论选哪个，跨端差异必须收口到一个 platform 模块里，分享参数构造、跳转小程序、获取系统信息这些各端行为不一致的地方统一封装，业务页面只调封装后的接口，不散写 wx. 开头的调用，否则换端排查时每个页面都要翻一遍。
2.3 版本号不是摆设：客户端把版本上报给服务端
v1.9.80 后面的加号看着像版本号，其实是客户端与服务端之间的契约暗号。微信小程序没有强制升级通道，旧版本客户端会一直留在用户手机上，接口字段一变，老版本就可能拿到新结构然后渲染异常。
常见做法是请求头统一带 X-Client-Version，值取自 wx.getAccountInfoSync().miniProgram.version。服务端按版本区间下发放量开关和字段版本，比如 v1.9.80 之前返回 discountText 字符串，之后返回 discountList 数组，接口层就要同时兼容两套字段，等老版本占比掉到阈值以下再删旧字段。这个清理节奏要写进接口文档，不能靠客户端开发每次发版时口头提醒。
3. 省钱数据的客户端组织：比价、券码与金额口径
省钱赚钱客户端的体验好坏，一半取决于券数据在客户端怎么组织。列表刷得快不够，还要保证「已领」「已失效」「已核销」这些状态在页面来回跳转时不闪变。下面按状态归属、增量刷新、金额口径三层讲。
3.1 状态归属：客户端只做标记，服务端说了算
券的领取状态是资金相关数据。一个典型错误是领券成功后把 claimStatus 写进本地 storage，用户换个设备、清掉缓存，本地状态和真实状态就对不上。更关键的是，券状态要作为风控依据参与服务端校验，客户端本地改状态没有任何业务意义。
| 状态 | 存储位置 | 更新时机 |
|---|---|---|
| 已领、已核销、已过期 | 服务端下发 | 每次领券/下单后返回 |
| 已读、已收藏 | 客户端 storage | 本地即时写 |
| 券列表整体缓存 | 客户端 storage | 按 TTL 失效 |
已读、已收藏这类纯 UI 状态必须放本地，它们不影响交易，服务端也没义务记。已领、已核销必须信服务端，前端拿到列表后把本地 viewState 和接口返回的 claimStatus 各显示各的，不要互相覆盖。用户从群卡片进 detail 页领了一张券，返回 list 页时 list 应该重新拉一次接口，而不是读两分钟前的缓存。
3.2 券列表的增量刷新：diff 出新券和失效券
券列表最常见的性能问题是下拉刷新时整页 setData。省钱客户端的券列表通常几百条，全量渲染一次耗时明显。常见做法是保留本地缓存列表，接口返回后用 couponId 做差量对比，只把变化的条目交给 setData。
function diffCoupons(remoteList, localList) { const localMap = new Map(localList.map((c) => [c.couponId, c])); return remoteList.map((rc) => { const lc = localMap.get(rc.couponId); return lc ? { ...rc, isNew: false, saved: lc.saved } : { ...rc, isNew: true, saved: false }; }); }couponId 是券的唯一标识，同时也是 WXML 里 wx:key 的取值；isNew 控制「新」角标，只在第一次出现时为 true；saved 是本地收藏状态，合并时从旧数据里带过来，避免收藏标记被接口数据冲掉。diff 完的数组还要反向检查：如果本地有某张券而 remoteList 里已经没有，说明它已失效，从渲染数组里移除。
diff 之前先做一次过滤：金额为 0、已领完、已下架的券直接不进渲染数组。把这三类数据挡在门外，列表页的渲染量通常能压掉三分之一，滚动性能和首屏耗时都受益。
3.3 金额一律用分：格式化与算价口径
优惠金额、返利金额、预计省多少，这些字段只要在客户端出现一次浮点运算，就有一次对不上账的风险。客户端与服务端之间必须约定金额单位是分，字段名直接写成 priceInFen、rebateInFen，杜绝「服务端传元、前端自己乘 100」这种写法。
function formatFen(fen, withSymbol = true) { const n = Number(fen); if (!Number.isFinite(n)) return '--'; const sign = n < 0 ? '-' : ''; const abs = Math.abs(n); const yuan = Math.floor(abs / 100); const rest = abs % 100; const text = rest === 0 ? `${yuan}` : `${yuan}.${String(rest).padStart(2, '0')}`; return withSymbol ? `${sign}¥${text}` : `${sign}${text}`; }先取绝对值再拼符号，避免负号位置错误；rest 用 padStart 补零，5 分钱显示成 0.05 而不是 0.5。格式化函数保持纯函数，不在里面做四舍五入，舍入口径由服务端定好，前端只显示结果。
比价功能如果走到前端算价，参与计算的字段必须全部是整数分。满减、折扣、运费叠加的顺序以服务端下发的 calcSteps 数组为准，前端不要自己发明「先减后折」还是「先折后减」。同一商品在列表页、详情页、结算页的优惠后价格必须一致，做法是服务端下发 unifiedPrice，前端三处都读这个字段，宁可多传几个字段也不让客户端重复计算。
4. 客户端与服务端的接口契约：登录态、缓存与请求排错
省钱赚钱客户端的业务代码可以写得糙，接口封装不能糙。券、返利、订单全和钱相关，任何一个接口的异常处理不当，用户看到的就是「领券失败但提示成功」或者「金额显示错乱」。这一章把接口层最常踩的三个坑按顺序讲。
4.1 静默登录与 401 重放：只重试一次
微信小程序没有传统 cookie 机制，登录态靠 wx.login 拿 code，服务端拿 code 换 openid 与 session_key，再发一个业务 token 给客户端。token 过期后客户端要做的是静默重新登录，而不是把用户踢回授权页。
function request(options) { return new Promise((resolve, reject) => { const run = (retried) => { wx.request({ url: options.url, method: options.method || 'GET', data: options.data, header: { Authorization: wx.getStorageSync('token') || '' }, success(res) { // 401 且没重试过时，重新登录后原请求再放一次 if (res.statusCode === 401 && !retried) { silentLogin().then(() => run(true)).catch(reject); return; } if (res.statusCode >= 200 && res.statusCode < 300) resolve(res.data); else reject(res); }, fail: reject }); }; run(false); }); }silentLogin 内部做完整的 wx.login 加 code2session 流程，成功后更新 storage 里的 token。retried 参数保证 401 只重放一次，防止服务端 session 异常时客户端陷入请求死循环。token 要放在 header 的 Authorization 里，不要塞进 data 随请求体发送，这样服务端鉴权逻辑统一，业务代码也不容易误改登录态字段。
4.2 缓存策略：页面配置和用户数据分两层看
省钱客户端的缓存分两层：页面配置缓存和用户数据缓存。首页的金刚区、banner、活动位属于配置，五分钟过期完全够；券列表属于用户数据，要短一些；秒杀、库存类数据不能缓存，过期一秒钟都可能让用户对着已下架商品下单。
| 数据 | TTL | 原因 |
|---|---|---|
| 首页配置 | 5 分钟 | 运营调整不需要秒级生效 |
| 券列表 | 1～2 分钟 | 领取状态变化快，太长老用户会看到已领券 |
| 秒杀/库存 | 不缓存 | 时效性直接关系交易 |
缓存读取写成通用函数，所有列表页共用一个实现：
function getCachedOrFetch(storageKey, fetcher, ttl = 120000) { const cached = wx.getStorageSync(storageKey); if (cached && Date.now() - cached.ts < ttl) { return Promise.resolve(cached.data); } return fetcher().then((data) => { wx.setStorageSync(storageKey, { data, ts: Date.now() }); return data; }); }fetcher 必须返回 Promise，ttl 单位是毫秒，默认两分钟。缓存命中时直接返回本地数据，页面立即渲染，再在组件里补一个后台刷新，让列表在用户看到之后悄悄更新。注意一个边界：接口返回空数组时不要缓存，空数组缓存两分钟，运营上架的新券就无法出现在老用户端，这是实际运营事故的高发点。
4.3 请求排查顺序：返回结构、状态码、耗时
客户端联调出问题时，别急着改代码，按顺序查三件事：返回体的 code 是不是 0，message 是不是业务提示，Network 面板里耗时是否超过 800 毫秒。省钱客户端的接口约定通常长这样：
function handleResponse(res) { const body = res.data || {}; if (body.code !== 0) { const err = new Error(body.message || '业务异常'); err.code = body.code; throw err; } return body.data; }code 为 0 固定表示成功，其余是业务错误码，比如 4001 表示券已领完、4002 表示券已过期。重点强调：不要拿 HTTP 状态码判断业务成败，HTTP 200 的返回值里也可能带着 code 4001。错误处理要区分网络错误和业务错误：网络错误提示「网络异常，请重试」，业务错误直接展示 message 原文，不要把 TypeError 堆栈抛给用户。真机问题用开发者工具的 Network 面板看请求链路，配合 vConsole 看控制台日志；接口返回慢时，优先检查是不是列表页在 onLoad 和 onShow 各触发了一次请求，同一个接口在页面生命周期里重复发，是省钱客户端耗时问题的头号来源。
5. 客户端小程序的体验分、灰度与跳转收尾
5.1 顶部导航栏高度与动态标题：自定义导航栏的两个必查点
省钱类落地页经常要自定义导航栏，把「已领 320 张」这类运营信息做成标题栏的一部分。自定义导航栏第一件事是量高度，量法基于胶囊按钮的位置，而不是猜一个固定像素。导航栏量错，页面内容被标题栏吃掉一块，微信开发者工具里跑体验评分时，首屏那一项先扣一大截。
function getNavBarLayout() { const menu = wx.getMenuButtonBoundingClientRect(); const info = wx.getWindowInfo(); const statusBarHeight = info.statusBarHeight || 0; return { statusBarHeight, navBarHeight: (menu.top - statusBarHeight) * 2 + menu.height }; }menu.top 减掉状态栏高度，得到胶囊上方留白，乘 2 加上胶囊自身高度，就是导航栏总高度。wx.getWindowInfo 从基础库 2.20.1 起替代 getSystemInfoSync，判断兼容性看基础库版本而不是客户端版本。动态标题在页面的 onLoad 里根据 path 参数调 wx.setNavigationBarTitle，不同群进来的用户看到不同文案，分享转化率通常能差几个点。
5.2 走分阶段发布，接口开关配合灰度
小程序客户端没有 App 那种精细到用户群的灰度能力，微信公众平台提供分阶段发布，按百分比放量，出问题就停发。但接口层可以自己做更细的开关：客户端请求头带版本号，服务端判断版本区间后决定返回新字段还是旧字段。回滚手段分两层：代码层回滚是重新发布上一版本，数据层回滚是直接关服务端功能开关，后者比前者快得多，所以关键接口的开关要提前埋好。
5.3 跳转链路的兜底：scheme 必须吃用户手势
从 H5 引导进小程序，微信里常用 URL Link 或 weixin://dl/business 这类 scheme。这类跳转只在用户点击手势里生效，异步回调里再触发大概率被拦截。客户端封装一层跳转，失败时兜底到小程序码。
function openMiniProgram(failCb) { wx.navigateToMiniProgram({ appId: 'wx1234567890abcdef', path: 'pages/index/index?from=h5', success() {}, // 手势或频率受限时，回退到展示小程序码 fail() { failCb && failCb(); } }); }navigateToMiniProgram 对调用时机和频率敏感，页面里存在「先请求后跳转」的场景时，点击后立即置 loading 遮罩，把跳转放在离点击最近的位置，失败统一走 failCb 展示小程序码。上架前的收尾清单里还有：类目与备案信息在提审前填完整，分享卡片配置正确的 path 和 query，否则从群卡片进来会掉到首页而不是指定的券详情页。接口字段变更要建一张对照表：字段名、生效版本、旧字段保留到哪个版本，把它和跳转兜底逻辑写在同一张检查单里，v1.9.80 之后的每次发版，先过一遍这张单子再提审。
本文还有配套的精品资源，点击获取
