企业官网建设流程全解析

简介：本资源是一套完整的微信小程序酒水商城实战项目源码，面向前端初学者及小程序开发入门者，旨在通过真实电商场景帮助掌握小程序核心开发技能。压缩包共58个文件，包含9个JavaScript逻辑文件、8个WXML页面结构文件、8个WXSS样式文件、8个JSON配置文件及24张图片资源，整体大小1.83MB，结构清晰，覆盖首页、商品列表、详情、购物车、订单、用户中心等典型模块。已有229人学习下载，体现了较强的实践参考价值。读者可直接运行调试，深入理解WXML/WXSS组件化开发、setData数据驱动、wx.request网络请求、事件绑定与购物车状态管理、微信支付对接流程等关键环节，并借鉴其页面路由设计与模块化组织方式，为后续电商类小程序开发提供可复用的代码范式与工程结构参考。 做了这么多年小程序开发，微信小程序商城的活儿接了不下二十个，这次整理的一份酒水商城案例源码，算是把这类项目的常规套路完整沉淀下来了。从登录授权、商品展示、购物车到支付订单，再到管理员后台的商品上下架和订单处理，一整套流程都是能直接跑的。如果你正打算做电商类小程序，或者想找一份结构清晰、能二次开发的源码做参考，这篇文章值得你花几分钟看完。我会把项目里最核心的设计思路、关键代码实现、以及开发微信小程序商城时容易踩的坑，全部拆开来讲。

1. 项目概述：一套能跑通全流程的酒水商城到底包含什么

1.1 从需求场景看这套源码的价值

先说说市面上小程序商城的现状。很多初学者在小程序开发者工具里导入一个源码包，发现页面能打开，但登录联不通、支付调不起、后台数据写不进，原因多半是前后端没有完整贯通。这套酒水商城案例源码之所以适合拿来学习和二次开发，就是因为它不是单纯的前端壳子，而是把前端小程序、后端服务、数据库和管理后台打通了，形成了一个可演示、可上线、可扩展的闭环。

所谓"可演示"，是指你导入工具后，修改少量配置，就能用测试账号跑通从浏览商品到提交订单的完整路径。"可上线"意味着接口权限、支付参数、域名白名单这些都已经按微信生态的规范预留了位置，缺的只是你自己的商户号和证书密钥。"可扩展"则体现在代码分层清楚，加一个促销模块、加一个优惠券功能，不需要推翻重来。

这套源码适合三类人：一是刚学完小程序基础、想做项目练手的开发者；二是产品经理或运营，想快速理解商城类小程序的功能边界；三是有定制需求、想在现成项目上快速改版的创业者。不管你是哪种角色，先花十分钟把目录结构看懂，后面就顺手多了。

1.2 为什么酒水品类能代表一类典型电商项目

有人可能会问，为什么偏偏是酒水商城，而不是通用的"XX商城"。这里的门道在于，酒水商品在电商系统里是最难做好的品类之一，比卖衣服、卖数码产品更考验系统的细节处理能力。

酒水有典型的规格属性：同一款酒，可能有单瓶、双瓶礼盒、整箱装，不同规格价格不同，库存独立，甚至条形码都不同。这就是电商领域常说的SKU（Stock Keeping Unit，库存量单位）管理。普通商品只需要把一张图、一个价格、一个库存丢上去，而酒水必须走规格组合，前端选择"规格"时，价格、库存、图片、条码要联动变化。这套源码里的SKU选择器，就是专门为一个商品挂多个规格设计的。

还有保质期和批次问题。酒类虽然是越陈越香，但啤酒、果酒、低度数预调酒都有明确保质期，仓储端需要按批次入库、按先进先出原则发货。后台如果不记录批次，过期酒水照样被当成正常库存卖出去，迟早出问题。源码里的库存表保留了批次字段，就是为这个场景设计的。

另外，酒水是高客单价商品，用户的支付信任门槛较高。小程序的支付流程、订单状态流转、售后处理都比普通商品要求更严谨。一套源码如果能把酒水这类复杂商品管理好，换成熟食、零食、美妆等品类，基本就是改改字段的事。

2. 技术选型与项目架构拆解

2.1 原生小程序 vs uni-app/Taro，我为什么这么选

市面上做小程序商城，主流技术方案有三类：微信原生小程序、uni-app、Taro。这套源码选用的是微信原生小程序加后端API的模式，并不是说其他方案不好，而是原生方案在商城这类复杂交互场景里，有它独特的优势。

原生小程序的开发语言是WXML、WXSS和JavaScript，微信开发者工具提供的调试体验最直接，编译速度快，API 调用的兼容性也最好。你写一句wx.request，工具就能直接帮你补全参数，真机调试的报错信息也最完整。相比之下，uni-app 虽然能一套代码多端复用，但在处理微信特有能力时，经常需要条件编译绕来绕去，遇到问题排查成本会高一些。

Taro 更适合团队中有 React 背景的开发，语法是类 React 的，但对于没有 React 经验的人来说，学习曲线也够陡的。

当然，这不代表原生方案没有短板。原生小程序不支持直接使用现代前端框架的组件化开发思维，但通过官方自定义组件机制，照样能把页面拆得足够细。这套源码里，商品卡片、数量选择器、订单状态标签，都封装成了独立组件，结构上并不输给 Vue 或 React 方案。

如果你是个人开发者或者小团队，我建议优先选择原生方案。原因很简单：市面上能百度到的周边生态、踩坑文章，90%都是原生小程序的。你遇到问题，搜解决方案的速度，直接决定开发效率。

2.2 目录结构与模块划分的心法

一个清晰的小程序目录结构，应该做到"见名知意"。这套源码的目录划分值得抄作业：

├── app.js # 全局逻辑，会话管理，全局配置 ├── app.json # 页面路由、窗口样式、分包配置 ├── app.wxss # 全局样式变量 ├── project.config.json # 项目配置，包含appid等 ├── pages/ │ ├── index/ # 首页，轮播、金刚区、推荐商品 │ ├── category/ # 分类页，左右联动布局 │ ├── goods/ # 商品详情页，SKU弹窗、加入购物车 │ ├── cart/ # 购物车，勾选、改数量、结算 │ ├── order/ # 订单列表与详情 │ ├── pay/ # 支付结果页 │ └── mine/ # 个人中心，地址、优惠券、设置 ├── components/ # 公用组件 │ ├── sku-popup/ # SKU选择弹窗 │ ├── number-stepper/ # 数量增减组件 │ └── empty/ # 空态占位组件 ├── utils/ │ ├── request.js # 请求封装，拦截器，token注入 │ ├── auth.js # 登录态管理 │ └── util.js # 金额格式化、时间格式化 └── api/ ├── goods.js # 商品相关接口 ├── cart.js # 购物车接口 ├── order.js # 订单接口 └── user.js # 用户接口

pages 目录下的页面全部通过app.json注册，分包策略也在这里配置。components 目录是所有可复用组件的家，这样首页和商品详情页想用同一个 SKU 弹窗，直接引用组件路径即可，不重复写逻辑。

api 目录单独放接口函数，是很多新手容易忽略的好习惯。不要在每个页面里直接写wx.request，而是把请求 URL、方法、参数统一封装在 api 模块里。这样一旦后端接口地址变了，你只需要改一个文件，而不是满项目搜索。

utils/request.js 是整小程序请求的中枢。它统一处理wx.request的封装，自动注入 token，收到 401 时自动跳转登录页，还能在请求头里加上版本号，方便后期接口治理。

2.3 前后端接口设计与数据表建模

后端接口遵循 RESTful 风格，资源用名词复数，动作用请求方法区分。比如GET /api/goods获取商品列表，POST /api/cart添加购物车，PUT /api/order/{id}更新订单状态。这种风格的好处是接口语义清晰，前端调用时基本不用看后端代码，猜都能猜出用途。

数据表设计上，关键几张表要单独拿出来讲：

product 商品表：id, name, main_image, detail_images, status, sort, created_at sku 规格表：id, product_id, name(如"500ml单瓶"), price, stock, barcode, image cart 购物车表：id, user_id, sku_id, quantity, checked, created_at order 订单表：id, order_no, user_id, total_amount, pay_status, ship_status, created_at order_item 订单明细表：id, order_id, sku_id, product_name, price, quantity user 用户表：id, openid, nickname, avatar, phone address 地址表：id, user_id, name, phone, province, city, detail

product 和 sku 是典型的一对多关系，一个酒水商品挂多个规格。order 和 order_item 也是一对多，一个订单里包含多种商品。之所以要拆出 order_item，是因为下单那一刻的商品名称、价格、图片需要固定下来。如果只记录商品ID，将来商品改名或下架，历史订单的展示就全乱套了。

库存扣减这块，源码里用的是预扣库存方案。用户提交订单时不是立即减库存，而是先把库存"锁定"，支付成功后再真正扣减，订单超时未支付则释放锁定。这样做的好处是避免高并发下用户拍下商品后无法支付的尴尬，同时也是所有正规电商平台都在采用的做法。

3. 核心功能模块与关键实现

3.1 微信登录与静默授权

微信小程序的登录流程，是很多新手第一次接触时容易懵的地方。先说结论：小程序的登录不是为了让你"登录"，而是为了把微信的 openid 和你自己后端的用户体系绑定起来。

登录时序分三步：

1. 小程序端调用wx.login，获取一个临时凭证 code，这个 code 有效期只有五分钟，而且只能用一次。
2. 小程序把 code 发给自己的后端服务器，后端拿着 code 加上小程序的 appid 和 secret，调用微信的jscode2session接口，换取 openid 和 session_key。
3. 后端查一下 user 表里有没有这个 openid，没有就自动注册一个新用户，然后用自己的加密算法签发一个业务 token 返回给小程序端。

// 小程序端登录核心代码 wx.login({ success: async (res) => { const { code } = res; // 将code发送到自己的后端 const loginRes = await request.post('/api/user/login', { code }); // 拿到自己后端的token wx.setStorageSync('token', loginRes.data.token); } });

这里有个细节值得提醒：不要把 appid 和 secret 写在小程序前端代码里。secret 是后端密钥，泄露了别人就能冒充你的小程序调用微信接口。正确做法是 secret 只保存在后端配置里，前端只传 code。

另外，wx.getUserProfile这个获取用户头像昵称的接口，在最新的微信基础库版本里已经做过调整，真实场景是用户点击授权按钮后触发。源码里已经处理了"未授权时用默认头像昵称"的降级逻辑，毕竟用户完全有权拒绝授权，你不能因为这个卡住不让下单。

3.2 商品列表与搜索排序

首页的商品列表，不是简单地把数据库所有商品查出来丢给前端。源码里做了三层处理：分页、排序、筛选。

分页是必须的，酒水商城动辄上百个SKU，全量一次性返回会拖垮首屏渲染。代码里采用传统的page和pageSize参数，后端返回total总数，前端据此判断还有没有下一页。

// 请求商品列表 export function getGoodsList(data) { return request.get('/api/goods', { params: { page: data.page || 1, pageSize: data.pageSize || 10, categoryId: data.categoryId, keyword: data.keyword, sort: data.sort || 'default' } }); }

排序策略在酒水场景下值得细说。默认排序通常按sort字段倒序，也就是后台手动控制推荐位。销量排序按sales_count，价格排序按price。后端在编写查询语句时，要注意 sort 参数做白名单校验，不能直接把前端传来的字段拼进 SQL 的 ORDER BY 里，否则容易产生排序注入风险。这一点虽然不在小程序端代码里，但在接口设计中一定要遵守规则。

搜索功能走的是后端的模糊查询，前端在搜索页监听输入框的bindinput事件，加一个 300 毫秒的防抖处理。不要用户敲一个字就发一次请求，否则后端瞬间会被打满，这也是实战中非常容易犯的错误。

3.3 商品详情页与SKU选择器

商品详情页是商城转化率的核心，酒水类商品的详情页尤其讲究。大图轮播要展示包装、酒体、背标信息，图文详情要展示酒精度、产地、原料、生产日期。源码里用swiper组件实现顶部轮播图，下方用 rich-text 渲染后端返回的富文本详情。

SKU选择器是整个商城里逻辑最绕的组件。用户选择一个商品，看到不同规格不同价格不同库存，本质上是前端在维护一个 SKU 组合矩阵。

举例来说：一款"金色年华"葡萄酒，有 750ml 单瓶、750ml 双瓶礼盒、整箱 6 瓶三个规格。每个规格的价格分别是 129、258、699，库存分别是 50、20、10。用户点开规格弹窗时，组件默认选中第一个有库存的规格，同时联动显示价格区间。

// SKU组件核心方法：根据选中规格更新展示信息 selectSku(skuIndex) { const sku = this.data.skuList[skuIndex]; if (sku.stock <= 0) { wx.showToast({ title: '该规格已售罄', icon: 'none' }); return; } this.setData({ currentSku: sku, price: sku.price, stock: sku.stock, selectedSkuText: sku.name }); }

这里要注意空库存规格的置灰逻辑：如果某规格库存为0，按钮要变成灰色不可点，而不是用户点击后才弹提示。这是提升用户操作效率的细节，也是源码里已经处理好的部分。

3.4 购物车与结算流程

购物车的核心逻辑不复杂，但细节多。勾选状态、数量增减、价格汇总、失效商品提示，每一项都要处理干净。

购物车页面的数据结构经过后端汇总，返回给前端的格式大概是：

{ "list": [ { "id": 1, "skuId": 101, "productName": "金色年华葡萄酒", "skuName": "750ml单瓶", "price": 129.00, "quantity": 2, "checked": true, "stock": 50, "image": "https://cdn.example.com/goods/101.jpg" } ], "totalPrice": 258.00, "selectedCount": 2 }

结算按钮点击后，前端做三件事：校验勾选商品是否为空、校验商品库存是否充足、拿选中的商品生成订单确认页。确认页展示商品明细、收货地址、配送方式和支付金额。酒水商城经常有满减活动，比如满299减30，这部分逻辑是前端根据总价计算出来的，因为后端在下单接口里也会做同样校验，双重保险。

提交订单时，后端接口参数至少要包含地址ID、商品明细列表、备注和配送时间。接口返回订单ID后，前端立即发起支付。

3.5 微信支付的对接细节

微信支付是小程序商城最敏感的一环，也是很多源码"跑不通"的主要原因。其实微信支付对接本身不复杂：前后端配合好一个流程就行。

流程是这样的：

1. 小程序端点击"去支付"，把订单号发给后端。
2. 后端收到请求，确认订单属于当前用户且未支付，然后调用微信支付统一下单接口，拿到prepay_id。
3. 后端用prepay_id生成支付参数（timeStamp、nonceStr、package、signType、paySign），返回给前端。
4. 前端拿到参数调用wx.requestPayment，拉起微信支付控件。

wx.requestPayment({ timeStamp: res.data.timeStamp, nonceStr: res.data.nonceStr, package: res.data.package, signType: 'RSA', paySign: res.data.paySign, success: () => { // 跳转支付成功页 wx.redirectTo({ url: '/pages/pay/result?status=success' }); } });

这里面最容易踩的坑是签名算法不一致。微信支付签名现在推荐使用 RSA 方式，和以前常用的 MD5 不同。用 MD5 做签名，在 2023 年以后的新商户号上会直接报错。所以源码里的签名实现是按照 RSA 来写的，这个细节如果你后期要接入自己的支付逻辑，一定要先确认自己用的签名类型是什么。

另外，支付回调是后端接收微信服务器发送的通知，用来更新订单状态。这个回调接口必须是公网可访问的 HTTPS 地址，并且要做签名验证，不能随便让陌生人伪造回调把订单改成已支付。

4. 实操过程：从零跑通这套源码

4.1 环境配置与工程导入

拿到源码包后，第一步不是急着看代码，而是把环境准备好。你需要：

• 一个注册好的微信小程序账号，拿到 appid
• 微信开发者工具稳定版，建议用最新版
• 后端环境，源码使用的是 Node.js 服务，需要本地安装 Node.js 16 以上版本
• MySQL 数据库，用于存储业务数据

导入工程时，在微信开发者工具中点击"导入项目"，把源码目录选进来，填好 appid。如果没有 appid，也可以先用测试号，但支付相关功能测试不了，因为测试号没有微信支付权限。

后端部署相对简单，源码里包含数据库初始化 SQL 文件。本地新建一个数据库，执行 SQL 文件，再把后端配置文件的数据库连接信息改成你自己的，最后启动后端服务即可。

4.2 需要修改的关键配置项

把源码跑起来之前，有几个配置项必须改，否则一定报错：

值得强调的是，微信开发者工具默认不允许请求 http 明文接口，本地调试时需要在工具右上角"详情-本地设置"里勾选"不校验合法域名"。这个选项只在开发阶段开，上线前必须关闭，并且把后端接口域名配置到小程序后台的 request 合法域名里。

4.3 从商品上架到支付下单的完整演示

弄好配置后，我建议你按这条路径完整走一遍，确认系统真的通了：

1. 启动后端服务，确认数据库表已自动初始化。
2. 打开小程序管理后台，手动录入一个测试商品，挂主图和详情图，添加两个SKU，比如"500ml单瓶"和"整箱装"，分别填价格和库存。
3. 小程序端进入首页，下拉刷新，确认商品出现在列表里。
4. 点击商品进入详情页，切换SKU，确认价格和库存联动变化。
5. 加入购物车，进入购物车页面，修改数量，点击结算。
6. 选择或新增收货地址，提交订单。
7. 到支付环节，如果是测试环境，后端可以配置一个"免支付"开关，跳过真实支付，直接模拟支付成功回调。

走到第七步，你就把一套商城的核心链路走通了。后面想接真实支付，只需要把你的微信商户号相关密钥填进后端配置里就行。

5. 实战踩坑与常见问题排查

5.1 小程序白屏问题与前端页面渲染

很多人在开发阶段会遇到小程序页面白屏的问题，尤其是在模拟器上编译正常、真机上却一片空白。这个问题的原因通常有两类：

第一类是 JS 报错中断了渲染。小程序页面渲染依赖 WXML 里的数据绑定，如果 JS 里某个对象为空，访问了不存在的属性，渲染就直接停了。排查方法很简单：打开调试器的 Console 面板，看有没有红色的报错信息，有就顺着堆栈找到具体代码。

第二类是分包或组件路径写错。如果引用了不存在的组件路径，编译阶段不会报错，但页面渲染时组件加载失败，整个页面就白屏了。我在源码调试时，遇到过usingComponents里路径大小写写错导致组件加载失败的情况，排查了很久。这里建议所有组件路径统一用小写字母加中划线的方式命名。

另外，一个很常见的场景是用 uni-app 开发小程序后，模拟器正常、微信开发者工具打开是白屏。这个问题通常出在编译模式或基础库版本不兼容上。解决思路是检查微信开发者工具的基础库版本是否过旧，以及 uni-app 编译出的分包配置是否正确。

5.2 顶部导航栏高度与安全区适配

小程序顶部导航栏高度，是另一个反复出现的坑。因为 iPhone X 以后的机型都有刘海，状态栏高度和导航栏高度在不同机型上完全不同。

静态写死padding-top: 64px的做法，在 iPhone 12 上可能还好，在 iPhone SE 上就会显得顶部空一截，在小屏安卓机上又会被刘海挡住。

正确的做法是动态获取系统信息：

const systemInfo = wx.getSystemInfoSync(); // 状态栏高度 const statusBarHeight = systemInfo.statusBarHeight; // 导航栏高度，胶囊按钮位置等信息 const menuButtonInfo = wx.getMenuButtonBoundingClientRect();

拿到statusBarHeight后，给页面的自定义导航栏设置padding-top，同时用safe-area-inset-top做兜底。这套源码里封装了一个navbar组件，所有页面统一使用，就是为了避免每个页面各写一套适配逻辑。

还有底部 TabBar 和 iPhone 底部 home indicator 的适配，采用env(safe-area-inset-bottom)解决，底部按钮的间距一定要加上这个值，否则 iPhone 用户会感觉按钮贴到了屏幕底部，点起来非常难受。

5.3 分包异步化与主包体积控制

微信小程序有主包不得超过 1.5MB 的限制，超过后上传代码直接失败。商城项目商品图片多、页面复杂，一不小心就会触碰这个红线。

解决方案是分包。把商品详情页、订单列表、用户中心这些二级页面全部放到分包里，主包只保留首页和公共组件。

源码里的分包配置：

{ "pages": [ "pages/index/index", "pages/category/category", "pages/cart/cart", "pages/mine/mine" ], "subpackages": [ { "root": "packageGoods", "pages": [ "pages/goods/detail", "pages/goods/search" ] }, { "root": "packageOrder", "pages": [ "pages/order/list", "pages/order/detail", "pages/pay/result" ] } ] }

分包之后还有一个优化点：分包异步化。默认情况下，主包访问分包页面时，需要跳转前加载分包，会有短暂的白屏等待。通过"分包异步化"配置，可以在主包代码中直接用require引用分包里的公共模块，减少等待时间。

使用require.async加载分包资源时，注意不要让页面跳转和分包加载产生竞争条件。我遇到过一种情况：用户快速点击两次跳转按钮，分包还没有加载完成，页面就启动跳转，导致导航失败。解决办法是跳转前加一个 loading 状态，并且防止按钮重复点击。

5.4 常见问题速查表

把开发中高频出现的问题整理成表，方便你直接对照排查：

这个表里的每一条，都是真实项目里见过多次的问题。尤其是酒水类目资质审核，很多开发者把功能都做完了，提交审核才发现自己没有食品经营许可证，导致小程序被驳回。这类事情要提前确认清楚。

6. 源码的二次开发与扩展方向

6.1 管理后台与权限控制

源码配套的管理后台，覆盖了商品、订单、用户、营销四大模块的基本功能。商品模块支持上下架、编辑、设置库存，订单模块支持发货、退款操作，用户模块可以查看用户列表和订单记录。

如果要在后台加一个运营角色，比如"运营专员"只能管商品、不能管订单，那么后端接口需要做权限控制。常见做法是在后端用一个中间件检查角色字段，把角色码和接口权限建立对应关系。代码里已经预留了 user 表的 role 字段，在此基础上扩展并不困难。

我建议优先给后台加上操作日志功能。电商后台多人操作是常态，商品改价、订单改状态、退款操作，最好都能留痕。将来出了问题，追溯起来会省很多事。

6.2 营销组件与同城配送的扩展思路

商城跑通基础交易后，下一步就是做增长和效率。这套源码预留了优惠券表结构，但没有把完整的领券、核销链路做完。扩展时可以基于现有订单金额计算逻辑，先在结算接口增加coupon_id参数，后端校验优惠券的有效期、使用门槛和使用状态，再把优惠金额从订单总价中扣减。

配送这块，酒水商城的同城配送需求很强。如果要做同城配送，通常有两种路线：自建配送员派单系统，或者接入第三方配送平台。自建的成本高，适合订单密度大的区域；接入第三方需要在用户下单后调用第三方创建订单接口，把取货地址、收货地址、重量等信息传过去，然后在小程序端实时展示骑手位置。

路线图建议按照"基础交易 -> 会员与营销 -> 配送与售后 -> 数据报表"这个顺序推进。每增加一个模块，都会对现有代码结构提出新的要求，但源码底子打得清楚，往上加东西不会伤筋动骨。

源码的价值从来不是让你直接拿去上线，而是让你知道一套正经的商城小程序是怎么组织的。我见过太多人拿到源码后第一件事是改标题、换图、传代码，结果第二天就问为什么首页加载不出来。老老实实把目录结构和数据表关系搞清楚，再动手改，才是省时间的做法。

最后再分享一个我做商城项目的习惯：永远保留一个最小可运行的版本不动，所有的修改都在副本上进行。这样即使改出问题，随时能回到那个能跑的版本上对照排查。这套酒水商城源码我也建议你这么用，先原封不动跑起来，再开始你的表演。

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