企业官网建设流程全解析

简介：这是一套开箱即用的微信小程序商城前端源码，面向小程序初学者、快速原型开发者及教学实践者，解决无后台依赖下构建完整电商展示与交互流程的需求。资源包含172个文件，以38个JS逻辑文件实现业务控制、23个WXML模板定义页面结构、26个WXSS样式文件保障UI统一，辅以55张PNG图标与轮播图素材，整体压缩包仅907KB，轻量易读易改。已有618人学习下载，适合用于课程设计、毕业项目或小程序入门实战。源码覆盖商城核心模块：支持客服电话与运费策略配置、模板消息对接、用户/商品/分类/品牌/轮播图/订单/促销等九大管理界面，所有页面均提供真实截图预览（如主页、购物车、支付页、订单确认页），并内置showdown.js等实用工具脚本，目录结构清晰，模块职责分明，便于理解小程序MVVM架构与组件化开发逻辑。 做微信小程序商城开发的朋友，应该都在各种资源站、GitHub、博客分享里搜到过这类标题：微信小程序-商城网站源码(不带后台)。我最早看到这类资源的时候也愣了一下，什么叫不带后台？下载下来一看，明白了——整个项目里没有管理后台的代码，商品数据是写死的静态JSON，购物车用的是本地缓存，用户登录走的是模拟流程，支付基本就是调一下API发个演示请求完事。说白了，这就是一个纯前端小程序壳子，把商城的前端流程完整跑通了，后端系统一概不涉及。

这种源码到底有没有用？我的答案是分情况。如果你只是练手、做毕业设计、给客户出静态演示demo、或者想快速上手微信小程序的整体开发流程，这类源码反而是高效的起点，结构不复杂，没有一堆后端服务要本地启动，克隆下来就能跑。但如果你指望它直接商用，那基本不现实，原因后面我会详细说。我前前后后接过几个小程序商城的单子，也自己从这种“不带后台”的源码改过项目，这里面的门道、坑和实操经验，这篇一份全说清楚。不管你是刚入行的小程序新手，还是想拿这种源码做改造的开发者，都建议把这篇看完再动手。

1. 先搞清楚：不带后台的商城源码到底长什么样

拿到这类源码，第一件事不是急着改代码，而是要搞清楚它的数据从哪里来、登录怎么走、状态怎么存。这三个问题弄明白了，你才算真正“看懂”这份源码。

1.1 没有后台不等于没有数据，数据都在前端

很多刚接触小程序的人容易误解，以为不带后台就是没有数据。实际上数据全在项目里。最常见的是三种形态：

第一种是直接用JS文件导出JSON对象，比如在/data/goods.js里写module.exports = { goodsList: [...] }，页面通过require引入这些数据然后渲染到界面上。这种方式最简单粗暴，一眼就能看懂数据结构。

第二种是把数据放在本地文件里，比如goods.json，然后用wx.request去请求一个本地路径。这里要特别注意，微信小程序在真机上是不允许直接请求本地文件的，只支持请求网络接口，所以这种写法在开发者工具里能跑，一上真机就白屏或报错。

第三种是用云开发，把商品集合放在云数据库里，前端通过wx.cloud.database()API去读取。但严格来说，云开发算半个后台，因为它有云函数和数据库，只是不需要你自己搭建服务器。市面上标注“不带后台”的源码，通常指前两种，第三种一般会单独标注“云开发版”。

这三种形态对应着不同的改造难度。如果你想往里面加数据、改价格、换图片，第一种最方便，直接改JS就行；第二种要看它请求的路径是不是合法域名，需要配置；第三种则是把数据放到了云端，管理起来反而方便，但需要开通云开发。

1.2 这类源码适合谁，又不适合谁

我这些年接触下来，找“不带后台”商城源码的基本是三类人：

第一类是纯学习的小白。刚从HTML/CSS/JS过渡到小程序开发，想看看一个完整的商城页面是怎么写的、页面跳转是怎么做的、tabBar怎么配置，这类源码结构简单，能直接告诉你答案，比文档教程直观得多。

第二类是做毕业设计或课程设计的学生。这类项目需求通常只要求“能演示”，不带后台反而省事，不需要搭环境，仓库里一拉，运到微信开发者工具就能跑，答辩演示完全够用。

第三类是接项目的开发者。比如客户先要看个demo原型，确认风格和功能了再谈后端开发，这时候直接用现成源码改UI效率极高，可能一晚上的功夫就出图了。

至于不适合的人群，也很明确：想直接开网店做生意的老板，想把小程序卖给客户然后收维护费的开发者，这类源码完全撑不住。原因无非是没有订单系统、没有用户管理、没有商品管理、没有支付回调。你在demo里看到的商品列表，可能只有五六个商品写死在文件里；没有后台意味着没有运营入口，连改个商品图片都得改代码重新发布版本，这在真实业务里是不可接受的。

说白了，不带后台的源码是很好的“练习册”和“原型工具”，但它不是“成品”。你要做的是基于它二次开发，而不是拿来即用。

2. 目录结构这样搭，后面写代码能省一半烦恼

很多新手拿到本项目，恨不得马上打开app.json改两行看看效果，我建议你先沉下心把目录结构摸一遍。一份好的商城源码，目录结构能看出作者的规划思路，这份直观也会影响你后续改动的效率。

2.1 一个标准的商城小程序目录应该有哪些部分

虽然每份源码的目录名称会有差异，但大体上逃不出这几层：

• pages/：页面目录，所有可见页面都放在这里。商城小程序一般有首页、分类、购物车、我的（这对应tabBar四个底部导航），还有商品列表页、商品详情页、搜索页、订单确认页、订单列表页等等。
• components/：组件目录，放置可复用的自定义组件。比如商品卡片、数量选择器、倒计时组件、空状态占位组件。组件化的设计会让首页和商品列表页复用同一个商品卡片模板，不用重复写样式。
• utils/：工具函数目录。常见的request.js（网络请求封装）、auth.js（登录状态管理）、cart.js（购物车本地存储操作）、format.wxs（价格和日期格式化）都在这。
• data/或mock/：静态数据目录。不带后台的源码，这里基本就是整个项目的“数据库”。
• static/或assets/：静态资源目录，放图标、默认图、一些本地图片。
• app.js：全局逻辑入口，主要做全局数据定义、登录态检查、版本更新提示。
• app.json：全局配置，页面路由、窗口样式、tabBar、分包配置都在这。
• app.wxss：全局样式表。

我强烈建议你把utils/request.js打开看看，这是整个项目是否便于二次开发的关键。官方仓库里常见的封装方式是这样的：

// utils/request.js const BASE_URL = 'https://api.example.com' function request(url, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${url}`, method, data, header: { 'Content-Type': 'application/json' }, success(res) { if (res.statusCode === 200) { resolve(res.data) } else { reject(new Error(`请求失败：${res.statusCode}`)) } }, fail(err) { reject(err) } }) }) } module.exports = { request }

这个封装很简单，但留好了扩展点。不管以后要加token、加拦截器还是换成云开发，都只需要改这一处。如果你拿到的源码里压根没有request封装，而是散落在各个页面里的wx.request，那这份源码的质量大概率不高，改造起来会很痛苦。

2.2 数据层拆出来是好习惯，哪怕没有后台也一样

我改造过几份商城源码之后，最大的体会是：无论有没有后台，都要把数据访问和页面逻辑分离。不带后台的源码最容易出现的问题就是页面里直接写死数据：

// 不推荐的写法 Page({ data: { goodsList: [ { id: 1, name: '商品A', price: 19.9 }, { id: 2, name: '商品B', price: 29.9 } ] } })

这种写法短期内没什么问题，但项目一旦变大，你会有十几个页面都要显示商品信息，每个页面都粘一份，数据不一致就是迟早的事。合理的做法是把数据源集中在data/goods.js里，页面require引用：

// data/goods.js const goodsList = [ { id: 1, name: '商品A', price: 19.9, image: '/static/images/a.png' }, { id: 2, name: '商品B', price: 29.9, image: '/static/images/b.png' } ] module.exports = { goodsList }

然后页面里：

const { goodsList } = require('../../data/goods') Page({ data: { goodsList: [] }, onLoad() { this.setData({ goodsList }) } })

这样做的好处在后期特别明显。假设你想把静态数据源换成云开发数据库接口，只需要在data/goods.js里改成异步请求，页面的展示代码完全不用变，数据结构保持稳定，界面层就永远不需要频繁改。

还有一点值得养成习惯：用storage存购物车和用户信息的时候，一定要用统一的key前缀，比如cart_list、user_info。之前有人在项目里用了carts和cartList两个key，页面间数据就会偶尔同步不上，排查起来特别费劲。约定统一命名，至少能少踩一半缓存的坑。

3. 核心页面逐个拆解：首页、商品列表、商品详情、购物车

商城类小程序的页面虽然多，但核心就那几个。把首页、商品列表、商品详情、购物车这四个页面吃透了，整个商城的骨架就到手了。我一个个过，注意听我说的坑，因为这些坑我自己都踩过。

3.1 首页：轮播图、金刚区和推荐位的数据流设计

首页是商城的面子，一般由轮播图、金刚区图标、活动楼层、商品瀑布流等部分组成。不带后台的源码里，首页数据通常是写在onLoad里的。你先别急着改样式，先想清楚首页需要哪几类数据：banner列表、navIcon列表、活动商品列表。这些数据分类存储，后续改动才方便。

比如轮播图数据，很多源码给的是远程图片URL。在开发者工具里能显示，但在真机上往往会因为域名没配置到downloadFile合法域名而加载不出来。如果你接手的是这种源码，要么把所有图片替换成本地图片，要么在公众平台后台加上域名白名单。本地图片放在static/banner/下，在data里引用绝对路径/static/banner/1.jpg即可。

首页还有个容易忽略的点是onShow与onLoad的区别。商城首页通常需要展示购物车角标，角标数量是存在本地缓存里的。如果你只在onLoad里读取一次，用户加购后切回首页，角标数量不会变。正确做法是在onShow里重新获取购物车数据并更新角标。

onShow() { const cartList = wx.getStorageSync('cart_list') || [] const totalCount = cartList.reduce((sum, item) => sum + item.count, 0) wx.setTabBarBadge({ index: 2, text: totalCount > 99 ? '99+' : String(totalCount) }) }

这里有个体验细节：如果角标数量为0，最好调用wx.removeTabBarBadge移除角标，否则数字0一直挂在导航栏上，看起来非常怪。

3.2 商品列表和商品详情：参数传错就是黑屏

商品列表页通常有两种入口：一种从首页金刚区或活动楼层点进来，一种从分类页点进来。列表页通过接收categoryId来筛选商品数据。页面跳转时参数传递用的是URL拼接，查错也基本从这开始。

下面这种写法很常见：

// 首页跳转到商品列表页 wx.navigateTo({ url: `/pages/goods-list/goods-list?id=${item.id}&name=${encodeURIComponent(item.name)}` })

接收参数时：

onLoad(options) { this.setData({ categoryId: options.id }) this.loadGoods() }

注意一点：如果商品名里有中文或特殊符号，跳转前一定要encodeURIComponent编码处理，否则在某些手机上会导致跳转后参数被截断，页面拿不到完整参数，呈现出来的就是空白或报错。这也解释了一部分人遇到的黑屏问题。

商品详情页相对复杂，除了接受商品id外，还要处理SKU选择、库存判断、加入购物车、立即购买。在很多不带后台的源码里，SKU其实是假的，只是前端做了个简单的规格弹窗，选中某个规格就弹一下“已选：红色/XL”，并不会真正区分库存。这个问题不大，演示足够了，但你要心里有数——后续接真实后端时，SKU数据结构的对接是逃不掉的，一般需要按“可选规格组 + 规格组合对应SKU + 价格库存”的结构来设计。

商品详情页还有一个性能优化的点，就是onLoad里不要一次性setData一坨巨大的对象。如果你有几十张商品详情图片，全部放到一个detailImgs数组里一次性setData，页面渲染会很卡。优化的做法是分页加载，先渲染前5张，滑动到底部时再追加后续图片。这个技巧在真实项目里很有用。

3.3 购物车：本地缓存方案的关键操作

不带后台的购物车，实现方式几乎全是基于wx.setStorageSync和wx.getStorageSync。不要小看这一块，踩坑概率极高。

购物车最核心的操作是增删改查：

• 加购：先读缓存，判断商品是否已存在，存在则数量累加，不存在则push进去。
• 修改数量：遍历数组，找到对应id，修改count字段。
• 删除：过滤掉对应id。
• 计算总价：reduce累加所有勾选商品的price * count。

每次操作后记得setStorageSync写回缓存。这里很容易出问题的地方是修改数量后忘记写回。我见过不止一次：页面上显示“ - ”按钮点了没反应，排查半天发现是商品数量改了，缓存没有同步。

举个例子，一个完整的修改数量方法应该是：

changeCount(e) { const { id } = e.currentTarget.dataset const { type } = e.currentTarget.dataset let cartList = wx.getStorageSync('cart_list') || [] const index = cartList.findIndex(item => item.id === id) if (index === -1) return if (type === 'minus') { if (cartList[index].count <= 1) { wx.showToast({ title: '最少购买一件', icon: 'none' }) return } cartList[index].count-- } else { cartList[index].count++ } wx.setStorageSync('cart_list', cartList) this.setData({ cartList }) this.calcTotal() }

购物车还有一个注意点：商品数据可能会变。缓存里存了商品价格和商品图片，如果你在编辑端改了价格，用户本地缓存的旧价格不会自动更新。解决思路是登录小程序时做一次缓存同步，拉取最新的商品信息覆盖缓存中的价格字段。不带后台的源码通常没有这层逻辑，但你心里得留着这个坑。

4. 订单流程、支付环节、用户体系：能演示但不能商用的大硬伤

商城小程序逃不开订单、支付和用户。这部分恰恰是不带后台源码“水分”最大的地方，也是真想商用必须要补的功课。

4.1 订单流程的模拟实现方式

不带后台的商城，订单流程一般是这样的：从购物车勾选商品或商品详情页点立即购买，跳到订单确认页，确认页展示商品清单、收货地址、金额明细，点提交订单后生成一个订单号，然后跳到“支付页”。这个流程走到支付这一步，通常就是做个假按钮，点一下弹个toast“支付成功”。订单数据会存到本地缓存，形成一份“订单历史”。

说得更直白一点，这份源码里订单的所有状态都是本地维护的，没有任何服务器来验证订单是否真实有效。对演示来说，流程完整即可，但等你要接入后端时，这一块基本要全部推翻重写。

真要做订单对接，有几个关键接口是必写的：创建订单接口、预支付接口（统一下单）、支付回调接口、订单查询接口。前端的页面可以复用源码里的样式和交互，但是订单号生成、金额计算这些幂等相关的逻辑，一定要放在后端。不要再拿本地时间戳当订单号，并发一高就会撞单。

4.2 微信支付这个坎，没有后台是真的迈不过去

这是整个商城源码里影响最大的一个“硬伤”：微信支付必须要有后端服务器来参与签名。微信支付的官方流程是：前端调起支付需要传入timeStamp、nonceStr、package、signType、paySign这五个参数，而这些参数必须由开发者服务器调用“统一下单”接口并获得返回结果后生成。小程序端直接调wx.requestPayment是拿不到合法参数的。

所以不带后台的源码，支付功能永远只能停留在“假支付”演示层面。你可以在开发者工具里弹个模拟支付面板，但点到真机上，它不可能调起真实的微信收银台。

想接真实支付，最轻量的方案是用云开发，云函数里可以调用微信支付的云调用能力。云函数拿到用户的身份信息和商品金额，在云端完成签名并返回支付参数，前端再发起支付。这样比起自己搭建完整的后端服务要省事得多，适合个人开发者和微小业务。

还有一点必须注意：微信小程序对虚拟支付管控很严。如果你卖的是虚拟商品（比如视频课程、电子书、在线服务），iOS端是无法使用微信支付完成的。这是平台规则，跟用什么技术方案都无关。商城源码里如果设计的是实物商品，这部分风险较小，但如果你卖的是会员之类的虚拟服务，建议对照微信官方的小程序虚拟支付规则看一遍，别等上线审核被打回来才想起来。

4.3 用户体系：没有后端怎么实现登录

正常的小程序登录是：前端wx.login拿到临时code，发给后端，后端拿着code去微信的开放接口换openid和session_key，然后生成自定义登录态token返回给前端。很明显，没有后端，这个过程也走不通。

不带后台的源码通常用两种方式绕过登录：一是直接存一份“假用户信息”到本地缓存，比如登录页让你输个昵称，保存就完事；二是用微信的“头像昵称填写能力”，让用户主动填写头像和昵称，前端拿到后存进 storage。

这里要提醒一下：如果需要拿用户的手机号，必须经过后台。手机号快速验证组件返回的动态token必须由服务器向微信接口换取真实手机号。没有后台，这一步无法完成。所以如果你做的商城必须依赖手机号做会员体系，这个功能在纯前端方案里是假不了的。

如果是用云开发，则可以通过wx.cloud.callFunction在云函数里使用cloud.openapi的能力完成登录态换取和手机号解密。这一方案比纯前端强得多，介于“不带后台”与“带后台”之间，适合中期改造。

5. 打包上线阶段，我整理的调试记录

开发完不代表结束，小程序还得过审核、正式上线。这一环节的问题，比写代码时更现实。很多新手在开发者工具里跑得好好的，一传代码就各种问题，我挑几个高频的坑详细说一下。

5.1 手机上看白屏，第一件事查这个

真机白屏问题我遇到太多次了。最典型的场景是：开发者工具一切正常，手机扫码预览，页面一片空白，console里也没有明显报错，或者只有一些无关紧要的警告。

排查顺序很重要。先看app.json里注册的第一个页面路径对不对。小程序启动默认加载pages数组中的第一项，如果这个路径写错，整个小程序直接白屏但工具里不一定报错。然后看页面onLoad里有没有运行时报错，特别是setData里传了 undefined 或者对象层级不对，真机上容易直接终止掉页面渲染。

还有一个常见问题：代码里使用了基础库之外的API，但project.config.json里设置的libVersion太低。真机上会直接调不到这个API，表现就是页面某个区块渲染不出来。建议把libVersion调整到与最近版本相差不要超过三个月的版本，既能用上新能力，又避免在太多老版本上不兼容。

最后就是网络请求问题。真机请求必须走HTTPS且请求域名已备案并配置到request合法域名。很多山寨源码里写的接口域名是假的，开发者工具开启“不校验合法域名”之后能跑，真机上所有请求全部失败，页面自然会白屏。

5.2 顶部导航栏高度和小程序的刘海屏适配

顶部导航栏高度是很多商城页面自定义头部时必踩的坑。如果你使用了自定义导航栏（在app.json或页面json里设置"navigationStyle": "custom"），那么你的页面顶部需要避开状态栏和胶囊按钮区域。

获取状态栏高度和菜单按钮位置有一套固定代码：

const systemInfo = wx.getSystemInfoSync() const menuButton = wx.getMenuButtonBoundingClientRect() const navBarHeight = (menuButton.top - systemInfo.statusBarHeight) * 2 + menuButton.height const statusBarHeight = systemInfo.statusBarHeight

这套逻辑的基本原理是：胶囊按钮的上边框到状态栏下沿的距离，约等于胶囊按钮下边框到导航栏下沿的距离。乘以2再加胶囊高度，就是自定义导航栏的总高度。这个计算方式在绝大多数机型上都适用，你在安卓、iOS、各种刘海屏水滴屏上都可以用同一套代码处理。要特别注意的是某些安卓机型的wx.getSystemInfoSync在横屏或分屏模式下会返回异常值，实现时最好加一层兼容判断，取值异常时回退到默认值。

5.3 分包和异步化的配置要点

商城类小程序如果商品图片多、页面多，很容易触达主包2MB的体积限制。这时候就必须使用分包。

app.json里配置分包：

{ "pages": [ "pages/index/index", "pages/category/category", "pages/cart/cart", "pages/mine/mine" ], "subPackages": [ { "root": "pagesGoods", "pages": [ "goods-detail/goods-detail", "goods-list/goods-list" ] }, { "root": "pagesOrder", "pages": [ "order-confirm/order-confirm", "order-list/order-list" ] } ] }

主包只保留tabBar页面和公共组件、公共工具，其他页面全部放进分包，主包体积立刻就能降下来。

分包异步化是个进阶优化点。比如商品详情页是从首页导航跳过去的，首页属于主包，商品详情页属于分包A。如果使用者网络情况一般，跳到分包页面时就需要下载分包A的代码，如果加载速度慢就会出现短暂的白屏或loading。分包异步化允许你预加载或者延迟加载一些分包资源，比如在首页通过wx.loadSubpackage提前预下载下一个包。配合缓存策略，可以明显改善跨包跳转时的加载体验。

5.4 防止截屏、前端上传文件等特殊需求的做法

有客户提过“小程序里不能截屏”的需求，这实际上不是要监听截屏行为，而是给页面做一次防截屏处理。微信提供了wx.setVisualEffectOnCapture这个API，调用后用户截屏时页面内容会被隐藏，只有设置的占位内容显示出来。这个API在iOS上的适配相对较好，Android上不同机型的表现略有差异，所以不要把它当作绝对的安全措施，只能说是增加截屏的难度。

关于前端直接上传文件到云端存储，比如上传到某个对象存储服务，在没有后台的情况下确实有一个曲线方案：在云函数中生成一个临时密钥，然后前端拿着临时密钥直接上传到对象存储。这样不需要自己搭一个上传代理服务。要注意的是临时密钥需要配置有效期和存储路径的权限范围，否则容易产生安全隐患。

6. 常见问题速查表与这几年的实操心得

这部分我把平时开发中被问得最多的问题整理成了一张表，另外补充一些自己的实操经验。

6.1 常见问题速查表

这张表不光是给小白的，很多时候你做了一两年项目，遇到某些现象第一反应也可能是“改样式”或“重新编译”，但根因往往是上述这些配置问题。建议截图存一份，排查的时候先过一遍。

6.2 几条干货心得

第一，改这种源码前，先花半小时整理一份“数据字典”。打开data/或者utils/里所有的数据文件，把商品字段、订单字段、用户字段列出来，理解每个字段的含义。这事儿看起来费时间，但真的能帮你省后期好几个小时的排查时间。尤其是那些命名不太规范的字段，比如img、pic、image混用的，不整理清楚后面改到一半就会懵。

第二，不要在setData里传包含大量函数的对象。小程序的setData是通过逻辑层和渲染层之间的桥接协议传输数据的，函数不会被正确序列化，传了也是白传，还可能引起性能警报。数据模型保持纯数据，所有方法都挂在Page或组件的宿主上。

第三，购物车、收藏列表这种频繁读写的功能，建议封装成独立模块。比如utils/cart.js对外暴露getCartList()、addToCart(goods)、updateCount(id, count)、removeFromCart(id)等方法。不要在每个页面里都直接操作storage字符串，一旦你以后要换成wx.syncCloud或者请求后端接口，只需要改这个模块内部实现，其他页面完全不用动。这是带后台改造时性价比最高的一次重构。

第四，也是最重要的：学会给自己留“后门”。不带后台的源码接后端的时候，切接口是最麻烦的。我习惯在utils/config.js里加一个总开关：

module.exports = { // true: 使用本地模拟数据；false: 使用远程接口 USE_MOCK: false, BASE_URL: 'https://your-api.example.com' }

每个页面的数据获取逻辑都判断这个开关。开发阶段用MOCK数据，后端就绪后把开关切掉即可。加上这个逻辑后，开发效率会高不少，而不是接接口时把页面逐个翻出来改。

结尾

最后说点个人体会吧。我见过太多人拿着这种“不带后台”的商城源码，试图直接改成商用项目，最后都被支付、订单、后台管理这类问题卡得死死的。但也正因如此，这类源码在学习和原型阶段的价值反而被低估了。你只要抱着正确的预期去用它，会发现它是一份极其难得的前端实践教程——小程序的核心页面、组件、路由、缓存、交互，一整套流程都摆在你面前，拿来拆解、练习、改造成自己的项目，成长速度比自己从零写快得多。我记得自己第一次完整啃完一份商城源码，再回去看小程序官方文档时，很多概念一下就通了。如果你也能把它当作“题目”而不是“答案”，哪怕最终没有成功上线，你学到的东西也一定不会亏。

如果后续有空，我打算再整理一篇具体的改造记录：怎么把这样一个纯前端商城改成云开发版，包括登录、支付、商品管理完整的链路，实际操作下来踩过的坑也不少，那篇可能会更长。先到这里。

本文还有配套的精品资源，点击获取