企业官网建设流程全解析

简介：一套完整的微信小程序商城项目源码，面向小程序开发入门者、Java后端学习者以及需要课程设计或毕业设计项目的在校生。项目采用前后端分离结构：后端以Java为主，包含业务逻辑、接口服务和数据库配置；前端除小程序原生页面（wxml、wxss、js）外，还提供基于HTML/CSS/JS的Web管理后台，用于商品、订单与用户管理。资源共2000个文件，涵盖java、js、html、css、wxml、wxss、json、xml、png、gif等类型，压缩包约37.89MB。目录中可见bootstrap、mui、swagger-ui等框架样式，说明项目已整合较完整的前后端技术栈。目前已有6422人学习下载，代码结构清晰，适合在此基础上二次开发，扩展营销、分销或优惠券等功能，也可作为电商小程序的实战参考。

1. 拿到微信小程序商城源码，先确认它是"工程"还是"交付物"

一个 zip 包、几百上千个文件，解压后大部分人直接去找"运行说明"或"打开按钮"，这是踩坑的第一步。微信小程序商城源码最常见的形态有三种：原生小程序工程、uni-app 工程、带后端接口的完整交付包，三种的打开方式、依赖关系、上线路径完全不在一个频道上。判断错了，后面装再多的依赖、配再多的域名都是白费。

我拿到这类源码的习惯是：先看根目录有没有app.json、project.config.json，或者manifest.json、pages.json这组特征文件，再看pages目录是否真实存在。这两个特征能在一分钟内锁定工程类型，也决定了后续用微信开发者工具还是 HBuilderX。第一章只把这个前置问题讲清楚，把"这是什么工程、需要哪些前置条件"对齐，后面的目录解析、代码改造和上线检查才有落点。

2. 微信小程序商城源码的目录结构、数据流与状态设计

2.1 先用三个文件认清源码的工程类型

原生微信小程序商城源码的根目录必然存在app.json、app.js、project.config.json，页面由.wxml、.wxss、.js、.json四件套组成。而 uni-app 工程的根目录则是manifest.json、pages.json、main.js，页面是.vue单文件，编译后才变成小程序页面。两种工程的目录长得像，但代码组织逻辑差别很大：原生小程序的app.json直接写页面路由和 window 配置，uni-app 则把全局配置放在pages.json中声明。

解压 zip 后别急着打开 IDE，先用命令行确认特征文件，比翻 README 更可靠。

# 确认原生小程序特征文件 ls app.json app.js project.config.json sitemap.json 2>/dev/null # 确认 uni-app 特征文件 ls manifest.json pages.json main.js 2>/dev/null # 两组都有输出时，再看页面源码后缀 find pages -name "*.wxml" -o -name "*.vue" | head -20

第一组命令有输出且页面是.wxml，说明源码可以直接导入微信开发者工具；第二组有输出且页面是.vue，说明它是需要先编译的 uni-app 工程；如果两组都没有，多半是完整交付包，小程序前端在某个子目录里，需要再定位一层。很多新手把 uni-app 工程直接拖进微信开发者工具，得到一堆"文件类型不支持"的报错，就是漏掉了这个判断。

工程类型与工具的对应关系整理如下：

另外可以顺手看project.config.json里的appid字段。如果值是touristappid，说明这个源码只是套了游客模式的示例模板，编译能过，但登录、支付、订阅消息全部不可用，必须替换成自己的小程序 AppID。

2.2 商城数据流：页面事件到接口的链路不能绕

商城源码不管页面多少，数据流都逃不开"页面事件 → api 模块 → 请求封装 → 后端接口 → setData 回填"这条链路。商品列表页的下拉刷新、首页的轮播图、订单列表的分页加载，最终都会落到某个接口函数。改源码前，我建议先把api/目录下导出的函数列出来，对照页面onLoad里调用的方法建立一张"页面 × 接口"的关系表，避免改了接口参数却漏掉调用方。

大多数商城源码会把wx.request抽到一个独立文件，因为登录过期、HTTP 状态码处理、请求头注入都集中在这一层。一个可用的请求封装大概是这样的：

// utils/request.js const BASE_URL = 'https://api.example.com' // 替换成你的后端域名 function request(path, options = {}) { const token = wx.getStorageSync('token') return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${path}`, method: options.method || 'GET', data: options.data || {}, header: { 'Content-Type': 'application/json', Authorization: token ? `Bearer ${token}` : '' }, success(res) { if (res.statusCode >= 200 && res.statusCode < 300) { resolve(res.data) } else if (res.statusCode === 401) { wx.removeStorageSync('token') // 登录态失效，回登录页 reject(new Error('登录已过期')) } else { reject(new Error(`请求失败：${res.statusCode}`)) } }, fail(err) { reject(err) } }) }) } module.exports = request

这里有两个参数需要注意：BASE_URL是后端接口根地址，开发环境可以用局域网 IP，但真机和上线必须换成 HTTPS 域名；Authorization是常见的 token 注入方式，有些源码用的是token字段或 Cookie，改动时要跟后端接口保持一致。401 分支是商城项目最容易漏的：用户 token 过期后，购物车和订单接口会连续报错，统一在这里清 token 并跳登录，比每个页面分别判断省事得多。

值得坚持的一点是：不要在页面里直接调用wx.request。商城上线后要换域名、加统一埋点、调整请求超时时间，如果这些逻辑散落在 40 个页面里，改一遍会怀疑人生。抽好这一层，后面所有改造都从它过。

2.3 登录态、购物车和收藏的缓存策略

商城源码里有三类数据高频读写本地缓存：登录 token、购物车列表、用户收藏。token 是请求凭证，必须持久化在wx.setStorageSync里，并配合 2.2 节的 401 分支做失效处理。购物车和收藏属于用户可操作数据，比较稳妥的做法是"本地缓存为主、接口同步为辅"：页面展示直接读缓存，操作成功后异步提交到后端，避免每次加减都要等网络往返。

一段常见的购物车缓存处理：

// utils/cart.js const CART_KEY = 'cart_items' function getCart() { return wx.getStorageSync(CART_KEY) || [] } function saveCart(cart) { wx.setStorageSync(CART_KEY, cart) // 同步 tabBar 徽标数量 const total = cart.reduce((sum, item) => sum + item.count, 0) wx.setTabBarBadge({ index: 2, // tabBar 中购物车所在的位置 text: total > 99 ? '99+' : String(total) }) } module.exports = { getCart, saveCart }

购物车缓存最大的坑是数量同步：加购、改数量、删除、清空四个动作必须走同一个saveCart入口，否则会出现页面显示数量与角标不一致。另一个坑是wx.setTabBarBadge的 text 超过 4 个字符后角标可能不显示，这里手动截成99+是兼容处理。收藏数据的存储结构建议用goods_id作为 key 的对象而不是数组，判断商品是否已收藏时，对象查找的效率更高，代码也更直观。

3. 用 HBuilderX 和微信开发者工具把商城源码跑通

3.1 AppID 用开发版还是测试号：选错会卡在编译

导入商城源码前，先确认project.config.json里的 appid。如果你申请了自己的小程序账号，用自己的 AppID 可以让登录、支付、订阅消息等开放能力在开发环境就正常调试；如果只是想看页面效果，在微信开发者工具里选"测试号"也能跑，但部分依赖 AppID 的接口（比如wx.requestPayment）会直接提示无权限。

测试号还有一个限制：没有真实 AppID 对应的业务域名，接口联调必须在开发者工具里勾选"不校验合法域名"。我一般在本地调试阶段用测试号，进入支付联调时换成正式 AppID，避免两边配置来回切换。前面提到touristappid要特别注意，不替换的话，编译后所有需要用户身份的按钮都会失效。

3.2 uni-app 商城源码先装依赖，再编译到 mp-weixin

识别出 uni-app 工程后，它不能像原生小程序那样直接拉进微信开发者工具。先在 HBuilderX 里打开工程根目录，确认manifest.json的小程序配置里填了 AppID，然后在工程顶层安装依赖。

# 工程根目录下安装依赖 npm install # 如果存在 package-lock.json，优先用 npm ci 保证版本一致 npm ci

装完依赖后，在 HBuilderX 菜单选择"运行 → 运行到小程序模拟器 → 微信开发者工具"。这一步 HBuilderX 会启动编译，并把产物写到dist/dev/mp-weixin。注意：微信开发者工具里导入的不是源码根目录，而是这个编译产物目录。很多同学报"app.json 找不到"，就是导入路径指到了 uni-app 的源码根目录。

HBuilderX 能自动唤起微信开发者工具的前提是：开发者工具开启了"服务端口"（设置 → 安全设置 → 服务端口），并且电脑上只有一个小程序工具的安装路径。端口没开时，HBuilderX 会提示编译成功但无法唤起，手动打开微信开发者工具并导入dist/dev/mp-weixin即可。

提示：不要把dist/dev/mp-weixin目录当作源码来改，它是编译产物，下一次构建会把改动覆盖掉。所有页面修改都回到.vue源文件进行。

3.3 本地调试关掉域名校验，真机必须走合法域名

本地调试时接口加载失败，90% 是合法域名校验在拦截。微信开发者工具右上角"详情 → 本地设置"里勾选"不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书"，本地连 http 接口就不会被拦。但要注意，这个选项只对开发者工具生效，真机预览和体验版都不认，别指望靠它蒙混上线。

真机上wx.request的域名必须是配置在小程序后台"开发设置 → 服务器域名"里的 HTTPS 域名，否则请求直接被判为非法。另一个容易忽略的点是 check 一下request.js里的BASE_URL来源，有些源码会按环境变量区分development和production，改的时候只改一处，不要连后端返回的数据结构一起动。

3.4 页面白屏与接口 404 的排查顺序

源码拉起来后遇到白屏，先看 Console 有没有红色报错；没有报错再看 Network 面板请求状态码。经验是报错信息优先，Network 其次。如果页面空白但请求都 200，问题大概率出在 setData 的数据结构，比如接口返回{ data: { list } }，而页面代码取的是res.data.list，字段层级对不上。

组件间数据传递也是白屏高发区。商城首页的轮播图组件如果监听传入的bannerList，而父页面在组件渲染前没有把数据 setData 进去，首次渲染就是空数组。一个常见的排查动作：在组件的attached生命周期里打印传入的 props 值，确认数据是否真正到达组件内部，而不是页面数据源就为空。

4. 商城源码四个高频改造点：登录态、商品列表、购物车与支付

4.1 从 mock 数据切到真实接口

很多商城源码为了演示，会把商品列表和首页数据写死在代码里。切真实接口时不要只改一个页面，先确认api/目录里有没有对应的商品接口函数。演示源码通常把 mock 数据放在mock/或data/目录，页面里直接import mockData from '../../data/goods'。改成真实接口后的典型代码：

const GoodsApi = require('../../api/goods') Page({ onLoad(options) { this.loadGoods(options.id) }, async loadGoods(goodsId) { wx.showLoading({ title: '加载中' }) try { const data = await GoodsApi.detail(goodsId) this.setData({ goods: data }) } finally { wx.hideLoading() } } })

这里要求GoodsApi.detail返回的数据结构与页面模板里使用的字段一致。比如 mock 里是goods.picUrl，接口返回goods.image，setData之后页面会显示空白。最好的做法是让后端对齐接口文档，或者在前端 api 模块里做一次字段映射，不要把映射逻辑散落在页面里，否则后面每接一个接口都要改一遍模板。

4.2 登录态与 token 刷新：不能只在启动时登一次

商城登录流程通常是wx.login拿 code，交给后端换 openid 和 token，之后请求带上 token。源码里常见的按钮登录和静默登录要区分开：静默登录用于进入页面时刷新会话，按钮登录在用户主动授权头像昵称后才触发。两套逻辑不要写成一坨，否则会出现授权弹窗反复弹的尴尬情况。

async function silentLogin() { const token = wx.getStorageSync('token') if (token) { return token } const { code } = await new Promise((resolve, reject) => { wx.login({ success: resolve, fail: reject }) }) const res = await AuthApi.login(code) // 后端用 code 换 token wx.setStorageSync('token', res.token) return res.token }

token 过期后的刷新机制更值得关注。很多源码只在启动时判断 token 是否存在，没有判断是否过期，用户在线逛十分钟后切到支付，接口才开始报 401。更稳妥的做法是在 request 封装里对 401 做一次静默重登，重登成功就重新发原请求，失败再跳登录页。注意防止多个接口同时 401 导致并发发起多次wx.login，常见做法是维护一个refreshing的 Promise 单例，让后续请求复用同一个重登流程。

4.3 购物车加减与本地缓存同步：角标和金额一起算

购物车加减在源码里一般拆成组件和页面两层：组件负责步进器 UI，页面负责更新缓存与后端同步。改造时最容易把count的变更漏掉一个入口，比如左滑删除走了另一套逻辑，结果本地缓存还留着旧数据。记住所有变更都必须经过saveCart这个唯一出口，删除和清空也不例外。

步进器组件的变更事件，在页面里的处理：

handleCartChange(e) { const { id, count } = e.detail const cart = getCart() const index = cart.findIndex(item => item.id === id) if (count <= 0) { cart.splice(index, 1) // 数量减到 0 时移除 } else { cart[index].count = count } saveCart(cart) }

这里的e.detail是组件通过triggerEvent抛出的自定义事件数据，带回了商品 id 和最新数量。每次改动都重写一次 storage，虽然批量操作时有点浪费，但商城场景下购物车操作频率不高，简单直接反而好维护。注意在组件triggerEvent时一定要带上商品 id，不要依赖回调闭包里的旧值，否则连续加减时容易出现 id 错位。

4.4 支付下单与回调验签：前端只做发起

很多源码把支付写得很"轻"，前端调wx.requestPayment传一个假订单号，这是不完整的。正确的链路是：前端先带着商品信息和 token 请求后端"下单"接口，拿到由后端签名生成的支付参数（timeStamp、nonceStr、paySign等），再把这些参数传给wx.requestPayment。前端自己拼支付参数一定会失败，因为paySign需要商户 API 密钥参与签名，只能在后端生成。

支付结果不能只看wx.requestPayment的 success 回调，那只是用户输入密码后的中间状态。最终结果以微信服务器回调后端接口的支付通知为准，后端在回调里验签并更新订单状态，前端再通过订单详情接口刷新页面。源码的后端部分如果有notify_url接口，检查它是否落库、是否做幂等，避免同一个支付结果推送两次造成订单重复发货。只有前端源码时，至少做到成功回调只跳订单详情页，不直接改订单为已支付状态。

5. 商城源码上线前：把包体积和请求明细过一遍

5.1 用代码依赖分析找体积黑洞

微信对小程序主包和分包的大小有明确上限，超过后上传编译就会失败。商城源码里最常见的体积黑洞是本地图片、字体文件和无用组件：几张商品图就能吃掉几 MB，未引用的组件也会一起打进去。打开微信开发者工具的"详情 → 基本信息 → 代码依赖分析"，按体积排序看一眼，再决定优化方向。

5.2 用 Network 面板找重复请求和慢接口

上线前把页面从头到尾走一遍，打开 Network 面板看两样东西：第一，同一个接口是否在多个页面重复请求，比如每次进入 tab 都重新拉一遍用户信息；第二，慢接口集中在哪，通常是商品详情页的聚合接口。对商城这种以列表为核心的项目，分页加载和骨架屏比全局 loading 更值得投入。

最后顺手做一件事：在构建产物里搜索console.log和TODO，把调试日志清理干净，正式包不要带冗余输出。经过这两轮检查，再把request.js的BASE_URL切成正式环境域名，打包上传体验版，邀请同事用真机把登录、加购、下单、收发货的流程走一遍，这套微信小程序商城源码才算真正具备了上线条件。

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