简介基于Vue和uni-app构建的Shopro分销商城开源源码定位于社交电商、小程序商城与公众号商城等场景适合需要快速搭建多端商城或希望深入掌握商城系统架构的前端开发者。整套源码共245个文件压缩包大小1.66MB包含153个Vue组件文件、56个JavaScript脚本文件、12个SCSS样式文件另附JSON配置、PNG图片、CSS样式等辅助内容从页面组件、业务逻辑到界面样式与项目配置均有清晰分层目录结构一目了然关键代码附有详细注释。目前已有718人浏览学习。其中Vue组件覆盖商品展示、订单流程、个人中心等常见模块JavaScript插件涵盖路由管理、表单校验、二维码生成、富文本解析等典型功能SCSS样式体系便于整体定制主题风格。无论是直接用于二次开发还是作为商城类项目的学习样本这套源码都能提供完整、可参考的实践路径。1. Shopro分销商城源码要解决什么场景问题一套带分销玩法的商城代码文件看起来差不多真正拉开差距的是用户与用户的推荐关系怎么存、订单返佣怎么算、钱怎么提。基于Vue和uni-app的Shopro分销商城开源设计源码把这条链路沉淀成了一整套工程前端一套代码输出H5、微信小程序、App后端管理商品、订单、分销员和佣金。适合两类人一类是电商团队想做私域裂变另一类是前端开发者想读一套真实商城源码了解营销系统在工程上怎么落地。开源不等于拿来即用。拿到的源码通常依赖旧版本Node或混着一堆兼容逻辑必须先跑通、再改业务才能变成自己的东西。下面前四章按模型、跑通、算账、排错的顺序推演最后一章给四个可直接用的改造点。2. 从Vue到uni-appShopro的工程结构与分销模型先立住先有一个总判断分销商城这类系统前端体验可以很花哨但决定上限的是数据建模和计算边界。把Shopro源码打开之前先在自己的脑子里把项目拆成四块用户身份、商品订单、分销关系、资金流水。前端负责把四块串成页面后端负责算账和记账。2.1 为什么选Vueuni-app而不是三端各写一遍Shopro选择Vue和uni-app核心是uni-app在编译期把.vue单文件分别编译成H5、微信小程序和App的运行代码。对商城这种页面密度高的项目商品列表、订单状态、分销中心这些模块代码复用率很高一套组件可以同时出现在三个端。对比原生多端开发节省的不只是写页面时间还有状态管理、请求封装和登录逻辑的重复劳动。版本上要特别注意Shopro有Vue 2和Vue 3两代分支很多老包还是Vue 2 vuex webpack的组合新项目则可能是Vue 3 Pinia vite。不要拿Vue 2的语法硬套Vue 3项目拿到源码第一件事是看package.json里vue、vuex或pinia的版本以及构建工具是webpack还是vite。Vue 3生态下uni-app的H5端和App端都由vite编译热更新快但依赖兼容性要求更严npm install时如果出现peer dependency冲突优先检查node版本是否满足engines字段。不过更重要的边界在于前端不宜承载分销核心规则。佣金比例、等级门槛、绑定关系这些如果写在客户端用户改个请求参数就能绕过。典型做法是后端在订单确认后按商品快照算好三份佣金前端只从接口拉取「可展示的佣金金额、等级名、提现余额」不参与金额生成。2.2 分销关系的数据表设计与三层边界多数分销商城把用户和分销员放在同一张用户表上用字段区分身份。基础模型大致是用户表users上挂is_distributor、distributor_level关系表记录parent_id和关系链或者用一个简单字段指向上一级推荐人。商品表存每个SKU的三级佣金比例或金额比如commission_rate_1、commission_rate_2、commission_rate_3。对应关系如下表数据常见字段承担职责用户表id, is_distributor, distributor_level用户基础身份分销关系user_id, parent_id, bind_time记录“谁邀请了谁”商品SKUcommission_rate_1/2/3三个层级的佣金比例订单表goods_snapshot, commission_log优惠快照与分佣依据提现表amount, status, audit_time资金流转记录这里有个容易忽视的点佣金计算必须依赖订单商品快照而不是实时查商品表。因为运营改价、加购、活动结束后历史订单的佣金与售后对账都以成交时点的数据为准。如果前端或后端直接按当下的商品比例算退货或者调价后会产生对不上的账。另一个边界是分销层级行业里比较稳妥的是三层以内的关系链原因可以理解成“越深的层级越难审计也越容易被刷单利用”所以你在Shopro类源码里看到的佣金字段也基本都是三级。2.3 动手前先读pages.json、manifest.json和storeuni-app项目的路由、导航栏和分包都写在pages.json里。商城首页、分类、购物车这些常驻页放主包分销中心、提现、佣金明细这类低频页面放分包避免小程序主包体积超限。一段典型配置{ pages: [ { path: pages/index/index, style: { navigationBarTitleText: 首页 } } ], subPackages: [ { root: pagesDistributor, pages: [ { path: index, style: { navigationBarTitleText: 分销中心 } }, { path: commission/index, style: { navigationBarTitleText: 佣金明细 } }, { path: withdraw/index, style: { navigationBarTitleText: 提现 } } ] } ], preloadRule: { pages/index/index: { network: all, packages: [pagesDistributor] } } }分包root会拼到页面路径前面所以pagesDistributor/index在代码里是页面路径。preloadRule的作用是首页加载后、网络空闲时预下载这个分包的资源分销中心入口跳转时白屏能明显变短。manifest.json负责端侧配置比如H5的baseURL、微信小程序的appid、App端模块权限。如果你用自己的小程序账号上线必须替换这里的appid否则登录和支付会一直报错。前端状态则统一放store里。多数Shopro前端用Vuex或Pinia维护token、userInfo和登录状态登录成功后把token写入uni.setStorageSync下次冷启动直接读storage恢复会话。下面是一个浓缩后的store写法// store/modules/user.js import { defineStore } from pinia export const useUserStore defineStore(user, { state: () ({ token: uni.getStorageSync(token) || , userInfo: null, inviteId: null, // 分享链接带进来的邀请人 }), actions: { setToken(token) { this.token token uni.setStorageSync(token, token) }, setInviteId(id) { this.inviteId id }, }, })注意这里把inviteId和token放在同一个store里原因稍后在分销绑定的章节展开绑定动作必须等登录成功后一起提交暂存到store是为了等登录回调触发。3. 在本地跑通Shopro前端环境、命令与首屏自检在写业务之前先让源码在自己的电脑上转起来。很多人在这一步卡住通常不是源码问题而是node版本和包管理器不匹配。uni-app官方推荐HBuilderX内置node但当你用CLI方式拉代码时还是得自己装一套完整node环境。常见做法是用nvm管理多版本配合.nvmrc避免换项目时来回切换版本。3.1 先把vue环境变量和依赖装到能启动的状态拿到源码后先看根目录有没有package.json再看engines字段// package.json节选 engines: { node: 16.0.0, npm: 7.0.0 }这里需要处理的就是典型的vue安装及环境配置问题。如果项目里同时出现node-sassNode 17以上几乎必挂解决最快的方式是把node切到项目指定版本再装dart-sass替代。依赖安装命令# 指定镜像站加速依赖下载不改lock文件结构 npm install --registryhttps://registry.npmmirror.com # 依赖装完后检查关键包是否存在 node -v npm ls vue dcloudio/uni-cli-shared 2/dev/null | head -20npm ls会把依赖树打印出来重点看vue、dcloudio相关包的版本是否一致。uni-app的编译器对版本比较敏感多个大版本混装大概率编译报错。如果项目是yarn workspace就用yarn install从HBuilderX创建的源码未必有package.json此时直接用HBuilderX打开项目目录运行也是常见做法。3.2 用npm脚本跑H5和微信小程序的命令与产物目录进来了先别改代码把「能启动」作为第一个里程碑。常见脚本长这样目标端脚本产物目录说明H5开发npm run dev:h5dist/dev/h5直接起本地dev server浏览器访问微信小程序npm run dev:mp-weixindist/dev/mp-weixin微信开发者工具里构建npm并导入支付宝小程序npm run dev:mp-alipaydist/dev/mp-alipay同理可导入支付宝IDE生产H5npm run build:h5dist/build/h5产出静态文件交由web服务器表里的产物目录是uni-app CLI默认路径如果你的项目改过vite或webpack配置以outDir为准。跑h5时如果后端接口还没就绪需要把后端地址写进.env.development并在前端请求层拼接。一份简化版环境变量文件# .env.development VITE_API_BASE_URLhttp://localhost:8080/api VITE_FILE_BASE_URLhttp://localhost:8080/files改动env文件后要重启dev server热更新不会自动重新注入环境变量这不是Shopro的bug而是vite设计如此。很多同事在这步反复确认“怎么改了没反应”。3.3 首屏跑通后按这5项做一次自检页面能打开只是第一步还要确认分销链路相关的前置条件都在页面正常渲染、请求没跨域、token能写入、分销中心入口出现了、并把当前登录人的推荐码存到了store。打开浏览器 Network 面板确认首页商品接口返回200且没有CORS错误。登录后打开StorageH5在DevTools Application里小程序在Storage面板确认token键已写入。在分销中心页面看「可提现余额」接口是否返回正常结构而不是401。分享一个商品链接从另一个微信账号打开确认URL上的referee_id被正确解析。用H5端把商品加入购物车并走一次订单流程排除支付相关报错。一次完整的本地跑通应该覆盖这两个端而不是只跑H5。小程序端要在微信开发者工具里关闭「不校验合法域名」才能访问http接口实际生产时必须在微信公众平台把request合法域名配成https地址。开发环境和生产配置的差异我在第五章还会专门补排障。4. 分销链路源码走读绑定关系、订单分佣与提现审核从页面角度Shopro的分销模块就是四五个页面分销中心、我的团队、佣金明细、提现申请、提现记录。源码真正的难度在于「关系怎么建立、钱怎么计算、申请怎么审核」这三个状态的切换。下面按链路顺序讲。4.1 邀请路径解析从分享到绑定用户A在商品详情页点「分享」B打开后进入页面。B侧拿邀请人的方式有两种H5是页面URL里的referee_id小程序是分享卡片携带的path参数场景值会出现在onLoad的options.scene里。拿到之后先存进store不要立刻调绑定接口因为B可能没登录。// pages/index/index.vue 节选 async onLoad(options) { if (options.referee_id) { this.userStore.setInviteId(options.referee_id) } if (options.scene) { // 小程序压缩过的场景值需要decode后再解析 const scene decodeURIComponent(options.scene) const match scene.match(/invite(\d)/) if (match) this.userStore.setInviteId(match[1]) } }登录成功后的回调里再调用绑定接口async loginSuccess() { await this.userStore.setToken(res.token) const inviteId this.userStore.inviteId if (inviteId inviteId ! this.userStore.userInfo.id) { await api.post(/api/distributor/bind, { referee_id: inviteId }) } }这里的两个参数要说明referee_id是邀请人的用户IDinviteId与当前登录人相同时直接忽略防止自邀自。绑定接口一般只会成功一次重复绑定会返回「已绑定」或升级关系被拒。这类接口的后端校验要考虑三件事邀请人存在且是分销员、被邀请人未绑定过、邀请人与被邀请人不是同一个人。如果只把parent_id存下来不做校验伪造请求直接把任意用户挂到别的团队最终清算佣金时会出大问题。4.2 订单分佣服务端怎么把三级佣金算出来前端在商品详情页展示的「邀请赚xx」一般来自商品详情接口的分销字段用于文案展示消费者真实下单后订单确认收货时后端触发分佣。一个典型的服务端计算示意// 伪代码示意分佣过程 $goods getGoods($order[goods_id]); $parent $user[parent_id]; $amount $order[pay_amount]; for ($level 1; $level 3; $level) { if (!$parent) break; $rate (float)$goods[commission_rate_{$level}]; $money round($amount * $rate, 2); if ($money 0) continue; insertLog([ user_id $parent, order_id $order[id], level $level, commission $money, status 0, // 0待结算 1已入账 2已退款冲抵 created_time time(), ]); $parent getParent($parent); // 向上取更上一级 }level就是邀请关系往上的第几层commission_rate_1到commission_rate_3对应三层比例。status用状态机控制而不是直接加进余额这样退款发生时就可以反向冲抵。前端要做的是在佣金明细页把接口返回的status翻译成文案0是待确认收货、1是已入账、2是已冲抵。很多用户投诉「佣金不见了」多半是订单还在待结算状态说明里要把这个状态变化讲清楚。不能把分佣算在前端的主要原因是分销比例属于运营数据放前端会暴露给所有访客并且篡改成本极低。4.3 提现申请的状态机与前后端联动提现接口提交时前端做一层基础拦截只是体验问题真实审核在后端。提交后生成一条withdraw记录状态依次是pending→approved→paid也可以出现rejected和refunded。前端只负责展示和调用// pages/distribution/withdraw.vue async onSubmit() { if (this.submitting) return this.submitting true try { const { data } await api.post(/api/distributor/withdraw, { type: this.type, // 1微信 2支付宝 3银行卡 account: this.account, // 账号或openid amount: this.amount }) if (data.code 0) { uni.showToast({ title: 申请成功等待审核, icon: none }) this.fetchBalance() } } finally { this.submitting false } }一个经常被忽略的参数是submitting锁定它防止用户连点两次产生两笔相同提现。另外后端在不做幂等时前端这个开关只减小误操作概率真正的安全边界要放在后端限流和状态校验上。提现金额还要满足最小限额余额扣除成功后余额变更与提现单写入必须在一个事务里完成否则会出现余额扣了但申请单没生成。提现状态可以配一个对照表前端不要自己意译状态含义前端展示0待审核审核中1审核通过待打款待打款2已打款已完成3拒绝已拒绝可查看原因5. Shopro多端兼容排错布局异常、WebView通信与条件编译到这里项目已经能跑能下单剩下的工作就是把各端的差异逐个磨平。uni-app的口号是“一套代码多端运行”但落到某个端上编译产物并不完全一致所以排错思路要从「为什么两端表现不同」开始。5.1 条件编译处理不同端的专属逻辑在vue文件、js文件甚至css里都可以写条件编译。下面这段是分销中心页面的常见处理小程序用button的open-type来触发转发H5没有这个能力只能换成复制链接。!-- 分销中心页面的分享区按平台编译 -- template view !--#ifdef MP-WEIXIN-- button open-typeshare邀请好友/button !--#endif-- !--#ifdef H5-- button clickcopyInviteLink复制邀请链接/button !--#endif-- /view /template条件编译在编译期完成没选中的端代码会被剔除因此H5包里不会残留open-type小程序的js包也不会多出复制按钮逻辑。注意它不是运行时if判断所以你不能用this.platform来写条件编译一旦写在运行时代码里两端的逻辑都会被打进去。5.2 vue打包后布局异常的三个来源H5预览没有问题build:h5或者小程序里布局乱掉这通常是样式的单位或图片路径问题。先排查下面三处症状常见原因处理方式文字大小不一致混用了rpx和px字体在不同的渲染引擎里基础大小不同字体统一用rpx或H5端用px配合postcss处理底部按钮被iPhone Dock遮挡没有适配安全区用env(safe-area-inset-bottom)做padding图片在小程序里裂开用了相对路径或http图片未配置下载域名图片URL改成https并在后台配置downloadFile合法域名vue打包后布局异常最常出现的原因其实是单位混用。rpx在小程序里按750宽设计稿缩放在H5上uni-app也会处理但是当页面同时出现px和rpx且写死在组件里微信iOS端的渲染结果就可能和Chrome不一致。解决办法是组内约定「布局一律rpx一像素边框用px」同时把公共样式里的字体大小抽到variables文件统一管理。5.3 小程序里的WebView如何与H5通信如果Shopro项目接入了自定义活动页面一般用web-view承载H5。很多人在这一张卡片上卡住H5页面如何把“领取优惠券成功”的消息回给小程序。需要明确的是小程序给H5发消息可以直接用webview.postMessageH5给小程序发消息在uni-app体系里要使用uni.webview.js并且会有时机限制。以H5通知小程序关闭webview并刷新列表为例// H5活动页 const message { action: reload } // 页面直接关闭时调用能带着数据回传给小程序端 uni.postMessage({ data: message }) // 随后用history.back或关闭按钮返回小程序小程序端在web-view组件的message事件里接收web-view srchttps://example.com/activity messagehandleMessage /message不是实时直达的它只在特定时刻上报比如web-view页面返回、分享、被销毁时所以不要想着H5发一条消息小程序立刻弹窗。更可靠的做法是把要传递的数据放在URL上或者让小程序端在返回事件里主动拉接口刷新数据。明白这个机制再去读源码里的webview相关代码就不会误以为message事件丢了。5.4 把官方toast换成可复用的全局弹出提示uni-app 官方 uni.showToast 的API在H5、小程序、App上表现差异很大iOS上文案过长还会被截断更常见的是没有icon自定义能力。我一般会封装一个全局toast组件定义一个响应式state通过pinia或provide注入组件挂载在根节点所有页面调用this.$toast.success(文案)。代码量不大但能统一各个端表现分销中心这类高频操作页面特别值得先改掉。6. 把Shopro调成你的分销体系4个直接能用的改造点每个项目最后都会问一句源码跑通了然后呢我一般会把下面四个点作为基线改造做完再去动业务。6.1 佣金比例改成接口下发不在前端写死分销中心的文案「邀请好友赚12%佣金」如果写死在代码里运营每次调比例都要发版。从接口拉取后再渲染金额数字还能保持与后端一致在store里维护一个distributionConfig对象登录后请求/api/distributor/config页面从store读取并展示缓存时间可设为5分钟。// 拉取分销配置的请求封装 export const getDistributionConfig () request.get(/api/distributor/config).then(res res.data) // 页面用法 const config await getDistributionConfig() this.rateText 邀请好友赚${config.rate1 * 100}%佣金6.2 用curl快速校验绑定关系是否生效修改绑定时机后是否需要反复点页面来验证? 不必。先拿一个测试账号的token再直接在命令行模拟邀请进入curl -X POST https://api.example.com/api/distributor/bind \ -H Authorization: Bearer test_token \ -H Content-Type: application/json \ -d {referee_id: 10086}返回里如果带out_referee_id或parent_name就说明绑定链路已经生效。注意这里要使用测试环境的接口地址生产环境不要用明文token去测试并且要随时在后台清掉测试关系。6.3 海报生成优先用canvas 2d而不是旧接口邀请海报是分销场景的高频功能Shopro类源码里常能看到用uni.createCanvasContext实现但新版小程序与App端都在向canvas 2d迁移。推荐用createSelectorQuery选中canvas节点再调用getContext(2d)。H5端绘制时注意外部图片域名需要允许跨域否则toDataURL导出会变成空白。6.4 给分销中心加preloadRule第2章的pages.json配置里已经出现了preloadRule但很多人会略过。这里补一句实际收益如果进入首页时能预下载分销分包用户从个人中心点进分销中心时白屏时间可以少300到500毫秒。配合分包体积控制在200KB以内效果最明显。加完之后用微信开发者工具的性能面板查看network waterfall。这几个改造点的共同方向是让运营数据和展示逻辑解耦、让验证链路可重复执行、让高频页面更快。跑通一套开源分销商城不难难的是把别人项目的默认设置迁移成自己业务的默认习惯。本文还有配套的精品资源点击获取