简介这是一套开箱即用的微信小程序商城前端源码面向小程序初学者、前端开发者及小型电商项目快速原型搭建者解决无后台依赖下的基础商城展示与交互需求。资源共172个文件包含38个JS逻辑文件处理商品筛选、订单流程、模板消息调用等、23个WXML结构文件构建首页、分类页、购物车、支付页等10核心页面、26个WXSS样式文件支持响应式适配与主题定制以及55张PNG图标与8张JPG轮播图素材整体压缩包仅907KB轻量易部署。已有618人学习下载源码结构清晰涵盖轮播图、分类、品牌、商品、订单、促销六大管理模块的完整前端呈现逻辑并内置客服电话、运费策略、VIP标识、模板消息ID配置等实用业务字段配合主页、购物车、在线支付等多张界面预览图可直接调试运行并快速二次开发。 拿到一份不带后台的微信小程序商城网站源码很多人第一反应是这玩意儿能干嘛没有后台商品数据往哪儿放用户下单了怎么处理其实我接触这类源码的次数挺多今天想认真聊聊它到底怎么用、怎么改、怎么从本地Demo变成能上线的小程序。这篇内容不只讲代码还把数据来源、核心模块、改造路径和排查经验都串起来适合刚接触小程序商城开发、或者准备拿现有源码做二次开发的人。先给这类源码定个性它不是半成品而是一种更轻量的技术方案。传统商城系统通常是小程序前端 Web管理后台 数据库 接口服务但不带后台的源码砍掉了后半部分所有业务逻辑都集中在小程序内部处理。好处是部署成本低个人开发者只用微信开发者工具就能跑通坏处是数据不能动态维护支付、会员这些能力需要自己补。如果你能接受这个前提后面很多问题其实都有明确的解法。1. 不带后台的商城源码不是半成品而是另一种思路1.1 先搞清楚不带后台到底不含什么你在网上下载、或者同事交接过来的商城小程序源码经常能看到这样的目录结构miniprogram/ ├── pages/ │ ├── index/ # 首页 │ ├── goods/ # 商品详情 │ ├── cart/ # 购物车 │ ├── order/ # 订单列表 │ └── user/ # 个人中心 ├── utils/ │ ├── request.js # 网络请求封装 │ └── util.js # 公共方法 ├── app.js ├── app.json ├── app.wxss └── project.config.json注意这套结构里没有admin目录没有server目录也没有接口域名配置文件。所谓的不带后台指的是它没有独立的Web管理端也没有后端服务代码。它的小程序前端是完整的页面、交互、跳转逻辑都在但数据可能是写死在代码里的也可能走的是第三方云平台。这类源码最典型的特征是你打开微信开发者工具导入项目填一个测试号AppID就能直接看到商城界面。首页有轮播图、商品分类、推荐商品列表点击商品能进详情页加购物车能看到角标变化部分连下单流程都有。但当你准备真正部署上线时就会发现没有后台意味着没有商品管理、没有订单管理换句话说前端演示得再好真要拿来经营还得靠你自己补全后端能力。1.2 这类源码最适合谁用我在实际项目中接过的商城小程程序大概分三类每一类对不带后台源码的态度都不一样。第一类是学习用途。初学者想搞懂小程序商城的前端实现比如列表渲染、页面传参、本地缓存、组件化这类源码是最好的教学样本。因为不需要搭环境不需要配数据库导入即跑读代码就能理解整个业务流程。第二类是出Demo给客户确认需求。接外包的时候拿一套现成的商城前端Demo给甲方看效果比从头写快得多。这个时候不带后台反而是优势你不用额外部署服务器在开发者工具里演示一遍首页、分类、购物车、结算流程客户看到的就是最终交互形态。第三类是个人开发者做轻量生意。假设你只卖几个单品商品数量少一天也没几单完全可以不用上传统后台。微信云开发本身就提供了数据库和云函数不带后台的前端代码配合云开发改造后能直接跑通真实业务连服务器都不用买。如果你不属于这三类而是想做一个需要复杂运营、多角色管理、大量SKU拆分的大商城不带后台这套东西就只能当参考最终还是会走上自建后台或采购成熟系统的路。1.3 和带后台版本的核心差异为了更直观地说明问题我把自己判断是否选用这类源码的维度整理成了表格对比项不带后台的商城源码带后台的完整商城系统部署环境微信开发者工具即可需要服务器、数据库、域名、HTTPS证书商品管理改代码/改云数据库后台可视化上架、改价、库存管理订单处理需自己写或放弃线下处理后台查看、发货、退款支付能力需额外开发对接通常内置微信支付/支付宝运维成本极低几乎零维护需要关注服务器安全和备份学习门槛适合前端初学者前后端运维都要懂上线周期短改完即用长开发联调测试部署流程多说句实在话我见过不少创业者被带后台三个字绑架明明产品还在验证期就花两周搭后台、做权限、写日志结果前端还没做好。如果你真的在起步阶段不带后台的源码完全可以作为第一版跑起来用户量上来了再补后台都不迟。2. 没有后台服务商城的商品和订单数据到底从哪儿来这是整个不带后台方案的核心问题。没有后端接口前端代码里的数据不可能凭空产生。我归纳了三种主流方案顺序是按照手动程度从高到低排的。2.1 方案一本地Mock数据最原始但最直观很多源码默认就是这么干的。数据通常藏在utils/data.js或者直接在Page的data对象里。比如// pages/index/data.js const goodsList [ { id: 1, title: 测试商品A, price: 99.9, image: /images/goods-a.jpg, categoryId: 1, stock: 100 }, { id: 2, title: 测试商品B, price: 59.9, image: /images/goods-b.jpg, categoryId: 2, stock: 50 } ]页面里直接 require 进来使用const { goodsList } require(../../utils/data.js) Page({ data: { goods: [] }, onLoad() { this.setData({ goods: goodsList }) } })这种方式的优点是零成本、跑起来绝对不会跨域、也不会遇到网络请求失败。缺点也明显改商品要改代码重新上传代码包用户下单也没人记录。它只适合技术演示和学习源码时用。2.2 方案二微信云开发给不带后台源码补上真正的动态数据微信小程序自带的云开发本质上是一套Serverless平台。不需要你自己买服务器它提供了云数据库、云函数、云存储三个核心能力。我给好几套不带后台的商城源码做过云开发改造思路都类似。先开通云开发环境在开发者工具里点云开发按钮按提示建环境即可然后在云数据库里创建商品集合、订单集合把Mock数据导入进去。小程序端通过SDK直接读库const db wx.cloud.database() Page({ data: { goods: [] }, onLoad() { db.collection(goods) .where({ status: true }) .orderBy(sort, asc) .get() .then(res { this.setData({ goods: res.data }) }) } })注意云开发数据库权限默认是仅创建者可读写你在云开发控制台手动导入的商品记录创建者是你自己那小程序端用户就看不到数据了。这时候要在云开发控制台把集合权限改成所有用户可读仅创建者可写或者用云函数做服务端读取。我习惯用云函数因为能控制返回字段、做分页、防刷权限也更安全。云开发的接入难度不大但有几个坑集合名称建议用连续小写字母不要用大写或中文不然排查起来很烦数据库请求有个数限制一次最多返回20条基础版真要做商品列表必须自己写分页逻辑。2.3 方案三对接已有API让不带后台变成假装有后台如果你手头已经有一个品牌商城的后端接口或者团队里其他人负责维护服务端那前端源码完全可以对接真实HTTP接口。只要把代码里所有直接读取本地数据的地方换成wx.request请求即可。// utils/request.js const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: https://api.example.com${url}, method, data, header: { Content-Type: application/json, // 通常要带上登录态 token Authorization: wx.getStorageSync(token) }, success: (res) { if (res.statusCode 200) { resolve(res.data) } else { reject(res) } }, fail: (err) reject(err) }) }) } module.exports request这种方式本质上是没有后台源码但借了别人后台的接口适合你有API文档但不需要把后台代码也一起拿过来的场景。这三种方案不是互斥的。我经常先本地Mock跑通界面然后用云开发把商品动态化最后如果客户要求对接他们的后端再把请求层切到真正的HTTP接口。改造的过程是一次性的只要前端数据流设计得清楚切换数据源的成本很低。方案适用人群是否需要服务器数据动态性实施成本本地Mock初学者、纯演示不需要无极低微信云开发个人开发者、小团队不需要高中对接真实API有后端配合者已有高中高2.4 我一般怎么选如果你拿到的不带后台源码里数据都是写死的我建议第一步先别急着接云开发而是把所有写死的商品数据整理成一份独立的JS模块统一导出。这样做的好处是将来不管换云数据库还是走HTTP接口你只需要改这一个模块页面里的代码不用动。这是很多新手容易忽略的一点——数据结构约定好了替换数据源才轻松。如果这个商城是给自己用我推荐直接上云开发它解决了小程序登录通过openid识别用户、消息推送、数据存储这几件事相当于一个被裁剪过的后台但没有传统后台那些复杂的权限和界面。3. 商城前端核心模块的实现思路拆解一套商城小程序不管带不带后台前端页面绕不开这几个模块首页/商品列表、商品详情、购物车、订单流程、个人中心。我在看源码时也是按这个顺序去确认代码质量。3.1 商品列表与商品详情从静态渲染到分类筛选绝大多数不带后台源码都会实现商品列表但实现质量差异很大。合格的做法是首页只展示推荐位分类页根据categoryId筛选数据商品详情页通过id拿到对应商品的完整信息。页面之间的传参方式是关键。小程序页面跳转时URL拼接是基本功!-- goods-list.wxml -- view classgoods-item wx:for{{goodsList}} wx:keyid bindtapgoDetail>// goods-list.js Page({ goDetail(e) { const id e.currentTarget.dataset.id wx.navigateTo({ url: /pages/goods/detail?id${id} }) } })商品详情页在onLoad里通过options.id接收参数再根据id找到完整数据。3.2 购物车本地缓存持久化与状态同步购物车在不带后台源码里通常用 wx.setStorageSync / wx.getStorageSync 实现因为购物车是用户的个人数据在没有用户体系的情况下本地缓存是唯一靠谱的存储位置。基础的购物车数据结构长这样// utils/cart.js const CART_KEY cart function getCart() { return wx.getStorageSync(CART_KEY) || [] } function addToCart(goods, count 1) { const cart getCart() const index cart.findIndex(item item.id goods.id) if (index -1) { cart[index].count count } else { cart.push({ ...goods, count }) } wx.setStorageSync(CART_KEY, cart) } function updateCount(id, count) { const cart getCart() const index cart.findIndex(item item.id id) if (index -1) { cart[index].count count wx.setStorageSync(CART_KEY, cart) } } function removeFromCart(id) { const cart getCart().filter(item item.id ! id) wx.setStorageSync(CART_KEY, cart) } module.exports { getCart, addToCart, updateCount, removeFromCart }一个小细节购物车里存的数据最好是商品快照包括标题、价格、图片、规格不要只存id。如果未来后台改了商品价格旧订单里的商品信息还能对上账。这个问题在有后台的商城里常常被忽略不带后台的本地缓存版反而天然规避了。购物车页面要注意的是总价计算。用 setData 更新整个数组性能没问题但总价必须遍历当前购物车数组动态计算不要自己维护一个totalCount变量因为任何一次数量和勾选状态的变化都会导致总价失效。3.3 订单流程没有支付网关的时候怎么模拟不带后台源码的订单模块通常有两种实现。一种是完全本地模拟用户在购物车点击结算跳转确认订单页选择收货地址点击提交订单后生成一个订单对象存到本地缓存里同时清空购物车。另一种利用云开发把订单写入云数据库。模拟支付的代码通常长这样submitOrder() { const order { id: Date.now().toString(), goodsList: this.data.cartList, totalPrice: this.data.totalPrice, status: pending, createTime: new Date() } // 没有真实支付能力只更新订单状态模拟支付成功 order.status paid const orders wx.getStorageSync(orders) || [] orders.unshift(order) wx.setStorageSync(orders, orders) wx.setStorageSync(cart, []) this.setData({ cartList: [], totalPrice: 0 }) }这里我需要特别提醒如果将来要接真实微信支付模拟支付阶段的代码结构不能乱。建议在提交订单时只生成待支付订单别急着把状态改成paid。真实支付流程是小程序端调用云函数或后端接口创建预支付单后端调微信支付统一下单接口拿到paySign然后小程序端wx.requestPayment唤起收银台支付成功回调之后再更新订单状态为paid。你提前把状态机设计成pending - paid - shipped - completed比后期返工简单得多。3.4 个人中心登录态的设计与变化个人中心在不带后台源码里是最容易被忽视的模块很多源码直接展示一个头像加昵称然后下面一排我的订单收货地址联系客服的入口。这里必须知道一个事情wx.getUserInfo 接口已经改版不能直接弹窗获取用户头像和昵称了。如果你用的源码还是老写法在现在的基础库版本下会静默失败或者只能拿到灰色默认头像和微信用户昵称。新的推荐方案是使用头像昵称填写能力button classuser-info-btn open-typechooseAvatar bind:chooseavataronChooseAvatar image src{{avatarUrl}} / /button input typenickname placeholder请输入昵称 bindbluronNicknameChange /也就是说用户主动选择头像路径主动输入昵称小程序再把这个头像上传到云存储或自己的服务器昵称随业务接口提交。在不带后台的本地版源码里你可以把昵称存到本地缓存展示没问题如果要跨设备同步就得上云开发了。4. 从拿到源码到跑通整个商城完整流程与关键配置这一节我按实际操作顺序讲每一步都给出我踩过坑之后总结的经验。4.1 环境准备和导入项目的四个注意点第一步是打开微信开发者工具选择导入项目然后选中源码根目录。很多人这里会卡住原因是源码目录选错了。注意 project.config.json 所在的那一层才是小程序项目根目录不是miniprogram目录的父目录你自己看源码结构来确认。导入时有四个配置需要注意AppID选择如果有自己的小程序AppID就填自己的没有的话选测试号也能跑通大部分功能但云开发、微信支付这些能力测试号不支持需要真正注册小程序账号。项目名称不需要和源码里的名字一致工具会读取project.config.json里的projectname自己可以改。ES6转ES5工具默认开启保持默认即可部分老源码依赖这个转换才能跑。不校验合法域名开发阶段必开否则wx.request请求http地址或未备案域名时会报url not in domain list。这个选项在详情-本地设置里。4.2 app.json与页面路径的检查清单导入项目后如果白屏或页面空白优先检查app.json。它是小程序的全局配置pages数组的第一项是启动页面。{ pages: [ pages/index/index, pages/goods/list, pages/goods/detail, pages/cart/cart, pages/order/confirm, pages/order/list, pages/user/index ], window: { navigationBarTitleText: 商城, navigationBarBackgroundColor: #ffffff }, tabBar: { list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/goods/list, text: 分类 }, { pagePath: pages/cart/cart, text: 购物车 }, { pagePath: pages/user/index, text: 我的 } ] } }如果pages数组里某个路径指向不存在的文件开发者工具会直接报错但报错信息可能不直观只是一句文件不存在。排查思路是打开控制台看编译日志的红色warning它会定位到具体缺哪个文件。sitemap.json 也值得看一眼。它是微信搜索索引的配置对商城这种需要被搜索到的项目来说默认允许索引即可但权限敏感页面比如用户个人中心不建议开启可以在页面json里覆盖配置。4.3 从开发者工具到真机预览最容易出问题的三个环节在开发者工具里一切正常真机上却各种问题这是小程序开发的经典玄学。我遇到最多的是下面三种情况。图片加载不出来。开发工具能显示真机显示空白绝大多数原因是图片地址是http协议或者域名没有配置到后台白名单。解决方案有两个要么把图片改用云存储里的地址要么下载到本地放到images目录要么在微信公众平台配置downloadFile合法域名。如果是http的图片微信直接屏蔽不能通过不校验合法域名选项绕过。canvas相关接口层级问题。比如热搜词里提到的video在部分安卓手机上层级最高挡住弹窗。这是小程序原生组件的历史遗留问题原生video、map、canvas组件的层级没法通过z-index控制。解决方案是使用cover-view覆盖或者换成同层渲染支持的基础库版本再或者用云开发的组件库/第三方组件里的替代实现。网络请求失败。真机上如果用了自签证书的HTTPS接口或者后端没配置好证书链wx.request会直接报失败。排查时用真机调试看Network面板不要只看开发者工具。开发者工具的request不会校验证书链那么严格真机更敏感。4.4 顶部导航栏高度与安全区域适配这是一个容易被忽略、但经常被搜索结果反复提问的点。小程序普通页面的导航栏由导航栏标题、胶囊按钮右上角的胶囊形状菜单按钮组成。胶囊按钮的位置在不同机型上不一样所以需要动态获取const info wx.getMenuButtonBoundingClientRect() const systemInfo wx.getSystemInfoSync() const navBarHeight (info.top - systemInfo.statusBarHeight) * 2 info.height这段代码获取的是自定义导航栏时导航栏的整体高度。如果源码里做了自定义导航栏页面顶部内容很容易被刘海屏挡住。正确做法是在onLoad里获取胶囊按钮信息把页面容器的paddingTop设置为胶囊按钮的top值或者用CSS变量来统一处理.page { padding-top: var(--nav-bar-height); }在不带后台源码里这条适配代码很可能缺失真机预览时你会发现首页首屏内容顶到了最上面观感很差。这也是检查源码质量时一眼能看出来的点。5. 从不带后台到真正上线改造路径与选型建议如果打算把这套源码变成真实运营的商城改造是必须的。我按改造顺序给出靠谱的路径。5.1 第一步把数据模型定清楚不要一上来就写代码。先列个清单商品需要哪些字段分类是单级还是多级订单有哪些状态要不要加收货地址要不要优惠券我一个个人项目的实际字段是下面这样的商品集合goods_idtitlecoverimagespriceoriginalPricecategoryIdstocksalesstatussort订单集合orders_idorderNouserIdgoodsListtotalPricestatusaddresscreateTimepayTime地址集合address_iduserIdnamephoneregiondetail注意在云开发里 _id 是数据库自动生成的不需要手动维护。订单号建议用时间戳加随机数生成不要用自增id并发情况下容易冲突。5.2 第二步选择云开发还是自建后端这个问题我每次都会被问到。直接给结论如果你是个人开发者或者项目预期用户量不超过几千直接用微信云开发。理由很实际不需要域名备案、不需要买服务器、不需要配HTTPS证书云函数天然解决了session和权限问题云存储解决了商品图片问题。如果你是团队开发有专业后端那不带后台源码只是一个前端资源后端自己搭Node.js/Java/PHP服务都行。前端请求层用我上面给的request封装改为对接后端接口页面逻辑基本不动。下表是我做方案评估时常用的对比维度微信云开发自建后端服务器成本基础版按量免费额度内够用需要买云服务器域名备案不需要需要开发效率快前后端同构慢需要接口联调数据控制权依赖微信平台完全自主适合场景小工具、轻商城中大型业务系统5.3 第三步登录、支付、消息推送这些要接的微信能力不带后台的源码通常跳过登录直接用本地缓存存一个假user。上线的第一步是把用户体系建立起来。用云开发时云函数里可以直接拿到用户的openid// 云函数 getUserInfo const cloud require(wx-server-sdk) cloud.init() exports.main async (event, context) { const wxContext cloud.getWXContext() return { openid: wxContext.OPENID, appid: wxContext.APPID, unionid: wxContext.UNIONID } }前端通过 wx.cloud.callFunction拿到openid后作为用户的唯一标识存入用户集合后续的订单、购物车、地址都挂在这个openid下面。这就是自建用户体系最省事的方案。支付要单独说云开发目前支持云调用微信支付需要在小程序商户平台绑定商户号然后云函数里通过 cloud.cloudPay.unifiedOrder 创建订单。这个流程比较长建议在开发阶段先用模拟支付把下单、订单列表、支付成功回调这些状态的流转先调通最后再接入支付参数避免调试支付时浪费大量时间。订阅消息也一样它是点对点的服务通知比如商品发货提醒。云开发里同样可以通过云调用发送订阅消息但订阅消息需要用户在小程序里主动授权一次模板授权后只能发送一次所以设计时不要让用户频繁授权。5.4 第四步把Mock数据替换成真实数据的操作顺序我推荐分三步走每一步都能验证。第一步把所有写死的数据集中到一个目录比如constants/mockData.js商品、分类、购物车、订单都从这里导入。第二步页面调用方式改成异步统一通过商城数据服务模块比如services/shop.js返回Promise页面里用then或await拿数据。这样将来无论切换云开发还是后端接口页面代码都不用动。第三步实现services/shop.js的云端版本内部调用云数据库或HTTP接口完成数据获取。验证通过后把入口从mockData切换成云端实现。这套模式在大型项目里叫Repository模式在小程序里不需要那么重但页面不直接操作数据存储这个习惯能让你以后改造时省掉大量时间。6. 开发调试中容易踩的坑按实际排查顺序整理最后这部分我把自己在调试商城小程序时遇到频率最高的问题按排查的先后顺序整理出来。6.1 开发者工具正常真机不显示图片或数据处理顺序是先看图片域名再看数据是否异步返回最后看是否有报错堆栈。如果是本地图片没问题远程图片要在微信公众平台后台配置downloadFile合法域名。域名配置是全局生效的但是有缓存改完等几分钟再试是正常的。如果是数据问题在真机调试面板里打断点或者console打印返回结果。真机调试的Network面板能看到请求状况比开发者工具更接近线上环境。6.2 购物车数据删不掉或者改了不生效这类问题的根源基本都出在缓存读写时机上。小程序setStorageSync是同步操作一般不会丢但如果多个页面同时读写同一个key就有可能出现覆盖。我的经验是购物车操作统一走utils/cart.js的封装的函数不要在某一个页面里直接setStorageSync写死数据否则整个项目里购物车逻辑有七八处根本改不动。另一个容易忽略的细节是商品数量加减到0时到底是从购物车里移除还是保留但显示置灰不可选中很多源码在数量减到0时会留下一个count:0的商品页面会显示小计¥0看起来很差。好的做法是数量小于等于0时直接在数组里过滤掉。6.3 网络请求间歇性失败报net::err_connection_aborted这个报错我在对接第三方接口时经常遇到。在小程序里最常出现的原因有几个后端接口响应太慢超过了小程序默认的60秒超时。后端接口的HTTPS证书链不完整部分设备和网络环境会拒绝连接。同一个接口在同一时间被并发请求太多次后端扛不住主动断连。排查顺序是先在开发者工具里看请求耗时把耗时超过3秒的接口列出来再用浏览器或curl测试接口是否正常最后检查后端日志确认有没有服务端异常。我遇到过一种情况是小程序端自己同时发起了多个相同请求导致后端重复处理。解决办法是在request封装里做一个简单的请求去重同一url同一参数的请求短时间内的重复请求直接复用第一个Promise。6.4 分包异步化和整体包体积的控制很多不带后台商城源码没有做分包。小程序主包体积上限是2MB一旦商品图片以base64形式内嵌在代码里或者把整个图表库打进去很容易超限。这时候要配置分包。把一些不常访问的页面比如订单详情、售后、会员中心放到分包里。分包配置在app.json里{ subpackages: [ { root: packageOrder, pages: [ pages/order/detail, pages/order/refund ] } ] }分包的异步化是一个高级优化点当用户从分包A跳转到分包B时如果B还没有下载完成默认会走等待下载的逻辑。微信提供了分包异步化的能力可以让公共逻辑代码异步加载减少首屏等待时间。但说实话商城类项目一般用不到那么精细只要图片不塞进代码包、接口返回数据不大量内嵌到页面json里主包控制在1.5MB以内体验都不会差。6.5 页面白屏控制台却看不到任何明文报错这是最玄的坑。我自己的排查顺序是先看app.js里是否有同步的wx.getStorageSync读取如果有读取失败或数据结构异常会直接阻塞整个app启动。很多老源码在app.js里放初始化逻辑一旦报错所有页面全白。再看app.json里页面路径是否正确。一个常见的低级错误是文件叫list.js页面路径里写的是index.js编译时不报错但真机运行白屏开发者工具也只能看到一个warn。最后检查页面的onLoad里有没有awaited一个没有被catch的Promise。如果数据源是云数据库而云开发环境没有开通或环境ID错误云函数调用会报错这个错误不会被页面捕获导致渲染数据一直是空的。解决方法是做一层错误兜底在页面上显示加载失败和重试按钮而不是默默白屏。结尾我把这套排查逻辑用在一个从网上下载的不带后台商城源码上前前后后只花了半天时间就把它从纯静态Demo改造成了基于云开发的可用小程序商品数据在云控制台维护订单同步到云数据库个人用户通过openid区分。整个过程没有引入传统后台但商城该有的业务闭环已经成立了。如果你手里也有一份类似的源码建议不要急着丢先按我上面说的流程把数据流摸清楚再做增量改造。等你真正把一款不带后台的商城折腾上线你对小程序前后端数据交互的理解会比直接套用一套完整系统深得多。本文还有配套的精品资源点击获取