微信小程序电器商城开发实战：从表结构到支付上线全解析

做微信小程序商城，尤其是电器类目的毕设或者个人作品，最容易出现的情况是：前端页面做得像模像样，一到后端接口、SKU数据结构和支付流程就露怯。我自己当初做类似项目时也踩过不少坑，从“能跑 Demo”到“能当作品答辩/上线展示”中间其实隔着很多细节。这篇就按我实际开发一套电器商城小程序的经验，从需求设计、表结构、核心页面到上线前的一堆暗坑，完整拆给你看，项目涉及的核心代码和配置也会直接给出来。

先界定一下这套项目的定位：这是一个面向“毕设作品”或“个人作品集展示”的微信小程序电器商城系统。电器类目比较特别，它不像卖衣服那样只分尺码颜色，它要处理能效等级、安装服务、以旧换新、大件物流等复杂商品属性，所以商品建模的数据结构是整站的地基，很多人把这一步做浅了，后面所有的筛选、详情、下单都会别扭。

1. 先想明白你要交付的是“作品”还是“商业小程序”

打开需求文档的时候，几乎所有人都会把功能列表写得很全：首页、分类、购物车、订单、支付、优惠券、秒杀……恨不得把京东电器搬进去。但作为实际要做出来的项目，第一步不是堆功能，而是确定边界。

1.1 技术选型：原生小程序与跨端框架的真实取舍

现在 GitHub 上搜“小程序商城”，一大半都是 uniapp 工程。为什么？因为很多人的电脑上装的是 HBuilderX，开发完一套还可以顺手编译到 App 和其他平台，简历上也好看。但如果你要交付的是微信小程序电器商城这个标题下的作品，我建议优先使用原生微信小程序开发，理由有三：

• 原生小程序的组件行为和官方文档完全对齐。遇到问题去社区搜，解决方案基本都是原生代码，你定位 Bug 的成本低很多。用 uniapp 的话，报错堆栈要先翻译一层“这是 uni 封装后的问题还是微信底层的问题”，对经验不多的人很不友好。
• 云开发或者自建后端时，原生小程序的 wx.request、wx.login、wx.requestPayment 链路最简单，没有中间层干扰。面试官或老师点开源码，看到的是清晰的 WXML/WXSS/JS，而不是一堆 uni. 前缀的封装。
• 电器商城这种项目，核心难点在于业务数据结构和状态管理，不在跨端。uni-app 的优势在于“多端复用”，但你的交付目标里并没有提到 App 端。

当然，如果你已经有 uniapp 基础，用 uniapp 也不至于翻车。只是后面我讲到的页面代码，会以原生小程序为主，uniapp 里把 wx. 换成 uni. 大部分也能对应上。

1.2 配套后端：自建接口还是小程序云开发

这是另一个容易纠结的地方。我的个人建议是：如果你的重点是展示小程序前端能力，后端直接用微信云开发；如果你需要在论文或答辩里写“系统架构”“数据库设计”“接口安全”，就自建一套后端接口。

云开发的好处是省去服务器部署、域名备案和 HTTPS 证书配置，登录鉴权也能直接用云函数搞定。但代价是云开发的数据库操作门槛其实不低，而且你在论文里不太好大篇幅画部署架构图。自然后端接口则需要一台服务器、一个备案域名和 HTTPS，这是微信小程序上线的硬性条件，逃不掉。

我自己当时的做法是用 Node.js 的 Express 框架搭后端，MySQL 存数据，Redis 存 token 和购物车缓存。这套组合生态最成熟，遇到问题网上一搜全都有，而且 Express 写起来比 Spring Boot 轻，适合个人项目快速成型。

2. 电器商城的需求差异，在设计表结构时就要开始

普通商城项目的数据库设计，无非是用户表、商品表、订单表、购物车表，四个表一拼就能跑。但电器商城不能这么糊弄，因为电器商品的属性维度和交易流程不一样。这里我把表结构里的关键设计拆开讲。

2.1 商品模型：从“一堆字段”到“SPU + SKU + 参数”

很多初学者会把商品表设计成一个大宽表：商品名、价格、库存、图片、分类……全部塞进一张表。这样做的后果是——当一个商品有多个规格时，你根本不知道库存该挂在谁头上。

比如一台空调，它可能有“1匹/1.5匹/2匹”三种功率规格，也可能有“变频/定频”两种类型，价格和库存都不一样。这时你必须有**SPU（标准产品单元）和SKU（库存量单位）**的区分。

• spu 表：存商品公共信息，比如商品标题、主图、详情富文本、品牌、类目 ID。
• sku 表：存具体可下单的规格组合，比如 “1.5匹 + 变频 白色” 这个组合，对应的价格、库存、条形码、SKU 图片。
• product_param 表：存电器的核心参数，比如能效等级、额定功率、净重、尺寸、保修期。参数有两种，一种是所有商品都有的公共参数，另一种是不同品类特有的参数，所以尽量用“参数名 + 参数值”的纵表结构，而不是给每类电器都新加一堆列。

这里有一个非常接地气的经验：电器商品详情页下方的“规格参数”栏目，很多学生项目都是前端写死静态数据，这样做在答辩时非常容易被追问。如果商品详情页里的参数全部从数据库里按品类读取，效果会好得多。

2.2 购物车、订单和售后，要提前考虑“拆单”

电器商城里，购物车表不能只存 user_id + sku_id + quantity。因为一个大件电器订单很可能会出现“冰箱和洗衣机同时下单，但两个商品发货仓库不同、物流不同”的情况，所以订单表要设计出 主订单 + 子订单 的结构，每个子订单对应一个商家/一个发货批次。这在真实商城里叫“拆单”，在答辩里叫“订单分表设计”，属于能加分的细节。

我的建议是至少建这几张表：

如果你还想加入“以旧换新”“上门安装”这类电器特色服务，可以加一张 service_order 表，把服务类型和预约时间单独挂出来。这个点在作品展示中很容易出彩，因为大多数模板商城都没有这个意识。

2.3 用户登录与 wx.login 的常见误区

别把用户表里的 user_id 直接存成微信的 openid，两者语义不同。正确做法是：

1. 前端调用 wx.login() 拿临时 code。
2. 把 code 发给后端，后端调用微信接口 code2Session 换 openid 和 session_key。
3. 自己生成一个 user_id 和 token 返回给小程序端。
4. 小程序端把 token 存到 storage，后续所有请求放在 header 里。

这里有一个很隐蔽的问题：wx.login 返回的 code 有效期只有 5 分钟，且只能用一次。如果你在后端调试时反复拿同一个 code 去换 openid，第二次必然报 code been used，不是说你的代码错了，是微信的机制就是这样。

3. 页面结构设计：首页、分类、商品列表的前端组织方式

小程序的包体积限制是 2MB（主包），虽然现在有分包机制，但你仍然需要提前规划页面。

3.1 tabBar 和页面目录的合理划分

对于电器商城，四个底部 tab 就够用：首页、分类、购物车、我的。不需要把“订单列表”放到 tabBar 里，订单在我-我的订单入口进。

开发时页面目录可以这样组织：

code复制pages/
  index/            // 首页
  category/         // 分类
  cart/             // 购物车
  user/             // 我的
  goods/
    detail/         // 商品详情
    list/           // 商品列表/搜索结果
  order/
    list/           // 订单列表（我的订单）
    detail/         // 订单详情
    confirm/        // 确认订单
  address/
    list/
    edit/

如果你把首页轮播图、金刚区图标、推荐商品全都在 index.js 的 onLoad 里请求，页面会出现长时间白屏。正确的做法是页面骨架屏 + 分块加载：优先加载轮播图数据，推荐商品区域可以由单独的接口返回，也可以在首屏完成后再异步请求填充。

首页作为小程序的第一视觉，尤其对于电器这种高客单价商品，用户更在意的是“可信度”而不是花哨的动效。想清楚这一点，你做的 UI 自然比那些“五彩斑斓的渐变首页”更适合项目调性。

3.2 自定义顶部导航栏：适配每一款手机的“刘海”和“胶囊”

热搜词里有人提到“微信小程序顶部导航栏高度怎么调”，我大概解释一下原生导航栏与自定义导航栏的区别。

原生导航栏最大的限制是样式单一，你无法把搜索框和导航栏融合在一起。电器商城里很多首页顶部就是搜索框，这个时候你会希望自定义导航栏。

但自定义导航栏必须自己解决状态栏高度问题。获取正确高度的方法：

javascript复制// 获取状态栏高度（单位 px）
const systemInfo = wx.getSystemInfoSync();
const statusBarHeight = systemInfo.statusBarHeight;

// 获取胶囊按钮信息
const menuButton = wx.getMenuButtonBoundingClientRect(); 

// 导航栏内容高度：胶囊顶部到状态栏底部的间距 + 胶囊高度 + 胶囊底部到导航栏底部的间距
const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height;

不要硬编码 64 或 44，因为 iPhone 和 Android 的高度差异极大。这段代码是全网通用的适配解法，你直接放到 app.js 的全局数据里，每个页面用 wx.getSystemInfoSync() 读取都有缓存，性能没有压力。

3.3 分类页与商品列表页的联动

电器商城分类通常采用左侧一级分类、右侧二级分类+商品列表的布局。左边用一个 scroll-view，右边用一个 scroll-view，点击左边分类时右侧滚动到顶部，并重新请求数据。

需要提醒的是：左右两个 scroll-view 一定要设置明确的高度，否则会出现整个页面滚动而不是局部滚动的问题。常见做法是用 flex: 1 撑满剩余高度，或者用 height: calc(100vh - 自定义导航栏高度) 来约束。

商品列表页的筛选条件，电器商城一般会有：综合排序、销量排序、价格排序、品牌筛选、能效等级筛选。这种复杂筛选条件的参数拼接很容易越写越乱，建议统一用一个查询对象管理：

javascript复制Page({
  data: {
    query: {
      page: 1,
      pageSize: 10,
      sort: 'default', // default / sales / price_asc / price_desc
      brandId: '',
      energyLevel: '',
      categoryId: ''
    }
  },
  onSearch() {
    const query = this.data.query;
    const queryString = Object.keys(query)
      .filter(key => query[key] !== '' && query[key] !== undefined)
      .map(key => `${key}=${encodeURIComponent(query[key])}`)
      .join('&');
    wx.request({
      url: `${app.globalData.baseUrl}/api/goods?${queryString}`,
      ...
    });
  }
});

这样你在修改筛选条件时，只需要更新 query 对象里的字段，再调用 onSearch()，接口请求参数不会漏。

4. 商品详情页和 SKU 选择：电器商城最容易做崩的地方

商品详情页是整个小程序交互最复杂的页面，它集成了轮播图、价格区、规格参数、SKU 弹层、加入购物车、立即购买、收藏、客服和售后保障入口。很多项目挂掉就是挂在这个页面的状态联动上。

4.1 SKU 选择器的状态设计

一个电器商品如果同时具备多个规格维度（功率、颜色、能效），前端需要根据用户已选维度来判断哪些规格按钮可点、哪些按钮缺货不可点。

先定义一个简单的数据结构：

javascript复制goodsSpecs: {
  specifications: [
    { name: '匹数', values: ['1匹', '1.5匹', '2匹'] },
    { name: '类型', values: ['变频', '定频'] },
    { name: '颜色', values: ['白色', '金色'] }
  ]
}

SKU 列表则包含每一条组合的记录：

javascript复制skuList: [
  { skuId: 1, specs: ['1匹', '变频', '白色'], price: 2199, stock: 10 },
  { skuId: 2, specs: ['1匹', '变频', '金色'], price: 2299, stock: 0 },
  ...
]

用户点选了商品规格后，需要实时判断某个 value 是否可用。最简单的暴力方法是：把当前已选的其他规格作为条件，过滤 SKU 列表，如果过滤后某条记录里没有当前规格值，则为不可用。

不过暴力方法有一个问题：当只选了“1匹”还没选“类型”和“颜色”时，你不知道“变频”可不可用，因为“1匹+变频”可能没有库存，但“1匹+变频+金色”有货。正确判断逻辑应当是：只要存在一个 SKU 的规格组合包含当前已选规格集合，并且该 SKU 中还包含待判断的这个 value，且库存大于 0，那么这个 value 就可用。

我贴一段核心代码：

javascript复制function getAvailableValues(specIndex) {
  const selected = this.selectedSpec; // 当前用户已选的值
  const currentSpecName = specifications[specIndex].name;
  
  // 判断某个 value 是否可点
  return specifications[specIndex].values.map(value => {
    // 尝试构造一个目标选中集合：当前规格选 value，其他已选项保持不变
    const targetSpecs = { ...selected, [currentSpecName]: value };
    const matchedSku = skuList.find(sku => {
      return sku.stock > 0 && sku.specs.every(spec => {
        // 只要用户已选的项存在，就必须匹配，未选的规格不判断
        return !targetSpecs[spec.name] || spec.value === targetSpecs[spec.name];
      });
    });
    return { value, available: !!matchedSku };
  });
}

这段逻辑不管你用原生小程序还是 uniapp 都适用，在技术面试里可以直接拿来聊“SKU 数据结构和算法”。

4.2 加入购物车和价格计算是两套独立逻辑

热词里有“购物车”，说明它就是高频痛点。购物车页的难点有两个：

1. 勾选状态管理
2. 价格联动计算

千万不要把购物车条目里的选中状态存到后端，频繁请求接口会卡顿。推荐的做法是：页面 cartList 里每条记录加一个本地 checked 字段，计算总价时只需要：

javascript复制const totalPrice = cartList
  .filter(item => item.checked)
  .reduce((sum, item) => sum + item.price * item.quantity, 0);

同时把所有被勾选的 SKU ID 收集起来，提交订单时传到后端校验库存和金额，再创建订单。为什么传给后端？因为前端算的价格只是展示，真正下单必须以服务端计算为准，否则用户改一下本地金额请求就能薅羊毛。

电器商品还有一个特殊之处——大件商品往往有“运费模板”，不同地区运费不同，或满额包邮。如果作品需要体现这点，建议订单确认页根据收货地址的区域编码去查一次运费模板，而不是在前端写死“满 99 包邮”。我当时为了图省事直接写死了规则，导致答辩时被问到“西藏新疆的大件电器运费怎么办”时愣了一下，后来赶紧把运费模板表补上。

4.3 手机软键盘遮挡输入内容，别只靠“调整窗口高度”

搜索框输入和收货地址填写时，软键盘会弹起并遮挡部分视图。很多人会用 adjust-position 或监听键盘高度来动态改变页面。但更自然的方案是：把需要输入的内容放在页面上半区，键盘弹出后依然可见；将“提交”按钮设计为吸底，通过监听键盘高度动态上推按钮位置。

小程序里监听键盘高度方法是：

javascript复制wx.onKeyboardHeightChange(res => {
  this.setData({
    keyboardHeight: res.height
  });
});

然后给底部按钮容器设置 bottom: keyboardHeight + 'px'。按钮会跟着键盘向上移动，不会被遮住。

5. 微信支付配置：支付看似简单，坑都在审核和资金流程

微信支付是电商项目里最敏感的一块，不仅是技术上要调通，还涉及商户平台里的一堆流程配置。

5.1 小程序支付“涉嫌违规被关闭”是怎么回事

搜索热词里有“小程序违规，支付功能暂时无法使用”，这通常是以下原因造成的：

• 小程序未通过微信认证，或个人主体小程序申请支付功能基本会被拒。
• 小程序类目与经营范围不符，你选的类目是“电商平台”，但营业执照范围里没有“网上销售”。
• 支付完成后没有及时的虚拟发货/物流单号回填，被判定为异常交易。

所以在开发阶段，不要急着去申请微信支付，先把商户号申请材料准备好，等小程序代码开发完、类目审核能过，再绑定支付。毕设展示里如果实在没有商户号，可以使用“模拟支付”按钮调通整个订单流程，但要在设计和答辩里说明真实支付场景下应该对接的是 wx.requestPayment。

5.2 前端拉起支付的时序问题

支付正确顺序是：

1. 用户在小程序点击“去支付”。
2. 后端创建订单，在微信支付接口里生成预支付交易单，拿到 payment 参数（内含 timeStamp, nonceStr, package, signType, paySign）。
3. 后端把 payment 返回给小程序。
4. 小程序调用 wx.requestPayment(payment)。
5. 用户输入密码或指纹支付。
6. 微信服务器异步回调你的后端通知接口，后端收到回调后把订单状态改为“已支付”。

你需要特别关注第 6 步：必须以微信支付服务器回调为准，而不是以 wx.requestPayment 的 success 回调为准。因为 requestPayment 的 success 只代表用户完成了支付动作，如果客户端断网，回调结果没发到后端，订单就会一直显示未支付。

我当时做的回调接口大概长这样：

javascript复制// 用 express 处理微信支付的回调
app.post('/api/pay/notify', (req, res) => {
  // 1. 验签（确认是微信发来的）
  // 2. 解析订单号和支付金额
  // 3. 校验订单状态和金额是否一致
  // 4. 更新订单状态
  // 5. 返回 { code: 'SUCCESS' } 给微信
});

整个流程但凡任何一个环节没做，都容易造成“用户付了钱，订单还是待付款”的尴尬情况。所以在开发时，不仅要测试支付成功，还要杀掉小程序进程模拟服务端收不到回调的情况，看订单在后台还能不能自动转成已支付。

6. 管理后台和接口层：让“商城系统”真正完成闭环

前台小程序页面做完，只算完成了一半。标题里写的是“电器商城系统”，不是“电器商城小程序前端”，所以一定要有一个简单可用的后台管理界面或者至少是完善的接口管理机制。

6.1 一份合格的后台需要哪些页面

如果做后台，至少需要覆盖这些模块：

• 商品管理：SPU 上下架、SKU 库存调整、参数编辑。
• 订单管理：订单列表、发货、退款/售后处理。
• 用户管理：查看用户基本信息与订单记录。
• 数据统计：今日销售额、订单数、热门商品 Top10（这个非常加分）。

后台的技术栈不强求，能实现功能即可。我当时用了 Vue2 + Element UI 做了管理后台，前端页面和小程序互补，在系统设计上构成完整闭环，展示效果比只做小程序好很多。

6.2 电商接口里容易被忽略的数据正确性问题

• 性能：商品列表接口分页必须用 LIMIT offset, size，但深分页会变慢，需要改成 WHERE id > 上次最大id LIMIT size，如果数据量很大，这是一个可以拿出来讲的优化点。
• 幂等：创建订单和支付回调接口要做好幂等处理，否则同一订单重复支付回调会导致数据错乱，一个简单做法是“先查订单状态，如果是待付款才更新为已付款”。
• 状态下钻：删除商品不能直接物理删除，应该用 status 字段做逻辑删除，否则会导致历史订单里关联商品信息丢失。

这些意识和能力，在答辩和面试中远比你会某个具体语法更有说服力。

7. 发布上线前的自检清单与几处容易失分的细节

如果你做到这里，时间还来得及，那上线体验版并不难。但上线前你要逐条检查下面这些点，其中不少是我自己经历过的“上线前才发现”的问题：

7.1 真机兼容：同一个页面在 iOS 和 Android 上的表现差异

这里分享几个实际案例，你就知道为什么必须用真机测试而不是只在开发者工具里看效果。

第一个是 Android 小程序里 video 组件层级过高和全屏错位的问题。电器详情页经常会嵌入产品宣传视频，小程序原生 video 组件是原生组件，层级在普通组件之上，容易和 swiper 嵌套后出现全屏错位，尤其是在 iOS 全屏播放然后退出时，页面布局会乱。一个有效规避手段是：不要在 swiper 里直接放 video，而是放视频封面图，点击后页面跳转或全屏播放，这样既满足需求又绕开原生组件的层级问题。

第二个是 iOS 底部安全区。iPhone X 及以上设备的底部有 home indicator，吸底购物车栏如果没做安全区适配，按钮会被“小黑条”挡住。适配方法：

css复制.safe-bottom {
  padding-bottom: constant(safe-area-inset-bottom);
  padding-bottom: env(safe-area-inset-bottom);
}

两个都写，旧的 iOS 也能自动忽略 env。

7.2 图片使用网络图片与域名白名单

小程序正式版中 wx.request 和图片域名都必须是 HTTPS，并且要在小程序管理后台配置“request 合法域名”和“downloadFile 合法域名”。但有一个坑是下载文件域名不配置会导致图片裂开。如果你商品图片直接放在自己的服务器上，只要配置一个域名即可；如果图片存到阿里云 OSS 或腾讯云 COS，还得把对应 bucket 域名也加进去。

开发调试时可以暂时在开发者工具中勾选“不校验合法域名”，但上线前记得取消勾选并真实配置合法域名，否则体验版一到手机就会请求失败。

7.3 体验版二维码 + 真机调试的排查链路

热词里有“小程序体验版二维码在哪”的问题。在微信开发者工具右上角点“预览”，会生成一个二维码，手机扫码即可进入体验版。体验版二维码有效期大约 30 分钟，过期需要重新生成。需要注意的是，体验版使用的人群必须在小程序后台的“成员管理”里被添加为体验成员，否则即使扫描二维码也会提示无权限。

真机调试时如果页面白屏或者数据不加载，排查顺序建议是：

1. 先看手机端是否打开了调试模式（vConsole）。在体验版页面右上角菜单里打开“调试”，能直接看到前端的报错。
2. 再用 curl 测试后端接口是否返回正常数据。
3. 再看请求 URL 是不是被微信拦截（此时 vConsole 里会明确提示 url not in domain list）。
4. 最后检查后端日志里是否有请求到达，如果根本没有请求进来，那就是网络层或域名问题。

这套排查链路对任何小程序问题都适用，熟练之后你会发现大部分问题的根源就三个：域名没配、代码里 URL 写错、真机和模拟器环境差异。

8. 作品答辩/项目展示时的讲解重点

项目已经开发完成，拿出去展示的时候，不要从头到尾按“首页、分类、购物车、我的”把功能过一遍，这不是展示项目，这是念用户手册。要让听众觉得你做的不是一堆 CRUD，而是你理解了一个电器商城系统的本质。

我总结的讲解思路：

• 先讲需求痛点：电器商品规格复杂、订单物流需要拆单、参数筛选和后服务链路长，这些是普通商城没有的建模难点。
• 再讲你如何用数据模型解决痛点：SPU/SKU、订单主从表、运费模板、售后单。这段直接体现你的系统设计能力。
• 然后挑一个技术难点重点展开：SKU 选择器的可用规格算法、支付回调的幂等处理、自定义导航栏的高度的适配，这些你深入讲三五分钟，绝对有专业度。
• 最后带上测试与部署：你如何保证支付结果不丢失、如何排查真机兼容问题、如何部署 HTTPS + 合法域名。这能证明项目不是“只能跑在开发者工具里”。

记住，作品成败不在于页面多华丽，而在于逻辑闭环和细节完整。把“为什么这样做”讲清楚，比把所有代码罗列一遍更有价值。

最后分享一个我长期保留的习惯：给每个后端接口都加一个请求日志中间件，记录请求路径、参数、响应时间。无论是日常调试还是别人评审代码，这段日志都能省下海量沟通成本。你把这个习惯迁移到任意项目里，一定能少走很多弯路。