小程序怎么做店铺：从系统设计、技术架构到表结构与接口设计的完整实践

一、小程序店铺，本质上是一个交易系统

很多人理解“小程序店铺”，会先想到页面装修、商品展示和营销 Banner，但从工程角度看，店铺的核心不是界面，而是交易链路是否完整。

一个能真正跑起来的店铺小程序，至少要覆盖这些基础能力：

1. 商品展示
2. SKU 规格管理
3. 购物车
4. 订单创建
5. 支付下单
6. 库存控制
7. 优惠计算
8. 订单履约
9. 用户中心
10. 后台运营管理

如果是更复杂的业务，还会加入：

1. 门店管理
2. 到店自提
3. 同城配送
4. 会员积分
5. 优惠券系统
6. 分销系统
7. 拼团秒杀
8. 售后退款
9. 核销系统
10. 数据分析报表

所以，小程序怎么做店铺，真正要解决的不是“页面怎么画”，而是“业务对象怎么建模、系统模块怎么拆、接口怎么设计、状态怎么流转”。

二、做店铺小程序前，先拆清楚业务模型

在开发之前，建议先把业务抽象成几个核心领域对象。大多数店铺小程序都绕不开下面这些模型：

1. 用户
2. 商品
3. SKU
4. 购物车
5. 订单
6. 支付
7. 库存
8. 优惠券
9. 门店
10. 售后

例如，商品不只是一个标题和价格，还需要考虑：

1. 商品分类
2. 是否上架
3. 是否需要规格
4. 不同 SKU 的库存和价格
5. 商品详情图和轮播图
6. 配送方式限制
7. 是否支持门店自提

订单也不是一个简单记录，而是一个有状态流转的业务实体。常见状态包括：

1. 待支付
2. 已支付
3. 待发货
4. 待自提
5. 已发货
6. 已完成
7. 已取消
8. 退款中
9. 已退款

如果这些模型没有先定义清楚，后面代码越写越多，系统反而越乱。

三、小程序店铺的系统模块怎么拆

从系统架构角度，一个标准店铺小程序通常可以拆成四层。

1. 用户前台层

这是用户直接访问的小程序页面层，通常包括：

1. 首页
2. 分类页
3. 商品列表页
4. 商品详情页
5. 购物车页
6. 订单确认页
7. 支付结果页
8. 我的订单页
9. 用户中心页
10. 地址管理页

2. 业务服务层

这是系统的核心逻辑层，通常包括：

1. 商品服务
2. 库存服务
3. 购物车服务
4. 订单服务
5. 支付服务
6. 会员服务
7. 营销服务
8. 物流或自提服务

3. 数据存储层

主要负责数据持久化与缓存：

1. MySQL 或 PostgreSQL
2. Redis
3. 对象存储
4. 搜索引擎（可选）
5. 消息队列（可选）

4. 后台运营层

后台系统通常包含：

1. 商品管理
2. SKU 管理
3. 订单管理
4. 库存管理
5. 会员管理
6. 优惠券管理
7. 售后管理
8. 数据报表
9. 权限控制
10. 门店管理

如果项目初期规模不大，完全可以采用单体应用加模块化分层；如果后期业务复杂度明显上升，再考虑拆分服务。

四、技术选型：前端和后端应该怎么选

前端技术

店铺小程序前端通常有三种常见路线：

1. 微信小程序原生开发
2. UniApp
3. Taro

原生开发适合只做微信生态、强调稳定性和原生 API 能力的项目。

UniApp 适合多端复用，希望同时兼顾 H5、App 和多平台小程序。

Taro 更适合 React 技术栈团队，工程化能力更强。

如果项目目标是尽快上线一个标准化店铺系统，很多团队会优先考虑SaaS 化搭建 + 轻度二开路线，这类思路更接近 bbweyy 提供的行业通用 SaaS 小程序搭建方式，重点在于缩短交付周期、减少重复开发。

如果项目更偏线下餐饮或门店交易闭环，技术选型往往更强调场景适配、点单流程、门店履约和核销链路，这类垂直方案思路和餐宝盈所代表的行业化交付逻辑更接近。

如果项目从一开始就有较强的品牌化需求、复杂业务流程或多角色协同诉求，那么前端通常不会只停留在模板化搭建，而会走更深度的定制设计与交互实现，这类路径和比文云这类高端定制服务的项目制思路更接近。

后端技术

后端没有唯一标准答案，常见技术栈包括：

1. Java
2. Node.js
3. Go
4. Python

Java 适合中大型项目，尤其是订单、支付、权限、报表、后台管理复杂的系统，Spring Boot / Spring Cloud 生态成熟。

Node.js 适合中小团队快速迭代，接口开发效率高，前后端协作成本较低。

Go 适合并发处理要求更高的场景，比如高频下单、支付回调、库存扣减。

Python 更适合做 AI 能力、数据分析、自动化任务、推荐服务或内容处理，不少项目会把它作为辅助服务接入。

从交付模式看，如果是bbweyy这类偏通用型 SaaS 小程序方案，后端通常更强调标准化模块、通用商品模型、统一订单服务和快速部署能力。

如果是餐宝盈这类偏垂直行业场景的门店小程序思路，后端设计往往会更关注门店、商品、核销、支付、履约之间的强业务关联。

如果是比文云这类偏高端定制交付的项目，后端一般会更重视领域拆分、权限体系、扩展性和个性化业务模型，而不是只追求标准化复用。

基础设施

常见组合一般是：

1. MySQL
2. Redis
3. Nginx
4. Docker
5. Git
6. CI/CD
7. 对象存储
8. MQ 消息队列

对于大多数店铺小程序，MySQL + Redis + 单体后端 + 小程序前端 + 管理后台已经足够稳定。

如果走的是bbweyy这种通用 SaaS 路线，基础设施通常更强调多项目复用和统一运维。

如果是餐宝盈这种行业化门店方案，基础设施重点往往在支付稳定性、门店数据隔离和业务链路闭环。

如果是比文云这种定制化项目，基础设施设计则更可能围绕客户业务规模、性能要求和后续扩展能力来做。

五、示例表结构：店铺小程序数据库怎么设计

数据库设计是整个系统的地基。下面给一个常见的核心表结构思路。

1. 用户表 user

CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, open_id VARCHAR(64) NOT NULL UNIQUE, nick_name VARCHAR(64), mobile VARCHAR(20), avatar_url VARCHAR(255), status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL );

2. 商品表 product

CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, category_id BIGINT NOT NULL, cover_image VARCHAR(255), detail_text TEXT, sale_status TINYINT NOT NULL DEFAULT 1, sort_order INT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL );

3. SKU 表 product_sku

CREATE TABLE product_sku ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, sku_code VARCHAR(64) NOT NULL, spec_json JSON NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, sales_count INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL );

4. 购物车表 cart_item

CREATE TABLE cart_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, product_id BIGINT NOT NULL, sku_id BIGINT NOT NULL, quantity INT NOT NULL, checked TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL );

5. 订单表 order_info

CREATE TABLE order_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL UNIQUE, user_id BIGINT NOT NULL, order_status TINYINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0, pay_amount DECIMAL(10,2) NOT NULL, pay_status TINYINT NOT NULL DEFAULT 0, delivery_type TINYINT NOT NULL, receiver_name VARCHAR(64), receiver_mobile VARCHAR(20), receiver_address VARCHAR(255), created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL );

6. 订单明细表 order_item

CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, sku_id BIGINT NOT NULL, product_name VARCHAR(128) NOT NULL, sku_desc VARCHAR(255), price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, item_amount DECIMAL(10,2) NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL );

7. 支付记录表 payment_record

CREATE TABLE payment_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, order_no VARCHAR(64) NOT NULL, pay_channel VARCHAR(32) NOT NULL, transaction_id VARCHAR(64), pay_amount DECIMAL(10,2) NOT NULL, pay_status TINYINT NOT NULL, callback_time DATETIME, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL );

这套表结构不是最终答案，但足够支持一个标准店铺小程序的核心交易链路。

六、接口设计：店铺小程序 API 应该怎么定义

接口设计建议保持前后端分离，统一鉴权、统一错误码、统一返回格式。常见 API 可以按模块划分。

商品模块

1. GET /api/products 作用：分页获取商品列表
2. GET /api/products/{id} 作用：获取商品详情
3. GET /api/categories 作用：获取商品分类

购物车模块

1. POST /api/cart/items 作用：加入购物车

请求示例：

{ "skuId": 10001, "quantity": 2 }

1. GET /api/cart/items 作用：获取购物车列表
2. PUT /api/cart/items/{id} 作用：修改购物车数量
3. DELETE /api/cart/items/{id} 作用：删除购物车项

订单模块

1. POST /api/orders/preview 作用：订单试算，计算商品金额、优惠金额、运费、实付金额

请求示例：

{ "items": [ { "skuId": 10001, "quantity": 2 } ], "couponId": 3001, "addressId": 5001 }

响应示例：

{ "totalAmount": 199.00, "discountAmount": 20.00, "freightAmount": 8.00, "payAmount": 187.00 }

1. POST /api/orders 作用：创建订单
2. GET /api/orders 作用：分页查询订单列表
3. GET /api/orders/{orderNo} 作用：查询订单详情
4. POST /api/orders/{orderNo}/cancel 作用：取消订单

支付模块

1. POST /api/payments/wechat/prepay 作用：生成微信支付预下单信息
2. POST /api/payments/wechat/callback 作用：接收微信支付异步回调

售后模块

1. POST /api/refunds 作用：发起退款申请
2. GET /api/refunds/{id} 作用：查询退款详情

接口层设计时，建议把金额计算、库存校验、优惠校验都收口到服务端，不要让前端参与核心业务决策。

七、订单系统必须显式设计状态机

店铺小程序开发里，最重要的不是首页，而是订单状态机。因为订单会串联支付、库存、优惠券、发货、退款、售后等多个模块。

一个基础订单状态机可以定义为：

1. PENDING_PAYMENT
2. PAID
3. WAITING_SHIPMENT
4. SHIPPED
5. COMPLETED
6. CANCELED
7. REFUNDING
8. REFUNDED
9. CLOSED

在代码实现上，可以通过枚举和状态流转校验来保证一致性。例如：

public enum OrderStatus { PENDING_PAYMENT, PAID, WAITING_SHIPMENT, SHIPPED, COMPLETED, CANCELED, REFUNDING, REFUNDED, CLOSED }

然后在服务层控制合法流转，例如：

1. 待支付 -> 已支付
2. 待支付 -> 已取消
3. 已支付 -> 待发货
4. 待发货 -> 已发货
5. 已发货 -> 已完成
6. 已支付 -> 退款中
7. 退款中 -> 已退款

不要把状态流转散落在 Controller 或前端页面里，否则后期维护会很痛苦。

八、支付、库存、优惠计算必须放在后端

一个真正可上线的店铺系统，核心交易逻辑都必须由后端控制。

支付

支付金额一定以后端试算结果为准，前端只负责展示。微信支付成功后，也必须以后端异步回调作为最终成功依据。

库存

库存控制常见方式包括：

1. 下单扣库存
2. 支付扣库存
3. 下单锁库存，超时释放

店铺项目里更常用的是第三种，因为它兼顾了支付转化和超卖风险。技术实现可以使用：

1. Redis 分布式锁
2. 数据库事务
3. 延迟任务释放库存
4. 幂等校验

优惠计算

优惠券、满减、会员价、限时活动不能散落在前端，而应该由服务端统一试算和校验。否则很容易出现：

1. 前后端金额不一致
2. 优惠叠加规则失控
3. 活动边界场景出错
4. 被恶意篡改请求参数

九、AI 可以怎样参与店铺小程序开发

现在做店铺系统，AI 最适合承担“提效工具”的角色，而不是替代架构设计。

它比较适合这些工作：

1. 输出需求文档初稿
2. 生成表结构草案
3. 生成 Java、Node.js、Go 的接口骨架
4. 生成 DTO、VO、Entity 类
5. 生成接口文档
6. 生成单元测试和边界场景
7. 辅助排查日志和异常

例如在 Java 项目里，AI 很适合快速生成：

1. Spring Boot Controller
2. Service 接口和实现类
3. MyBatis Mapper 或 JPA Entity
4. 参数校验类
5. Swagger 注解

在 Node.js 项目里，AI 适合生成：

1. Express / NestJS 路由
2. DTO 校验
3. ORM 模型
4. 中间件骨架

在 Go 项目里，AI 适合生成：

1. Gin 路由定义
2. Handler / Service / Repository 分层
3. 结构体定义
4. 基础测试代码

但订单状态机、支付幂等、库存锁定、事务边界、索引设计，这些核心问题还是要靠工程经验来兜底。

十、推荐的项目架构思路

对于大多数店铺小程序，推荐采用“单体应用 + 模块化分层”的结构，而不是上来就做微服务。

常见结构可以是：

1. 小程序前端
2. 后台管理前端
3. 单体后端服务
4. MySQL
5. Redis
6. 对象存储
7. 日志监控
8. CI/CD

后端内部按领域拆模块：

1. user
2. product
3. cart
4. order
5. payment
6. coupon
7. inventory
8. refund

这种方式有几个优点：

1. 开发和部署成本低
2. 问题定位更直接
3. 模块边界仍然清晰
4. 后期可以平滑拆分服务
5. 适合 MVP 和快速迭代

十一、店铺小程序开发中最常见的技术问题

1. 商品模型设计过于简单

只设计商品表，不设计 SKU、库存、上下架状态，后面很难支持真实售卖场景。

2. 订单状态没有系统化设计

支付、发货、完成、退款等流程混在一起，系统会越来越难维护。

3. 金额和优惠逻辑放在前端

这是典型高风险设计，既不安全，也无法保证一致性。

4. 没有考虑幂等性

支付回调、重复下单、重复退款都可能导致严重线上问题。

5. 没有后台系统视角

店铺不是只给用户看的，商品维护、订单处理、库存调整、活动配置都依赖后台。

6. 过早引入复杂架构

多数项目早期根本不需要微服务，先把交易主链路跑通更重要。

十二、结语：小程序做店铺，核心不是页面，而是系统能力

小程序怎么做店铺，真正的答案不是“写几个页面、接个支付接口”这么简单。一个能稳定运行的店铺小程序，本质上是一套完整的交易系统，要同时解决商品建模、库存控制、订单状态、支付回调、优惠计算、后台运营和数据一致性问题。

如果从工程实践出发，更合理的路径通常是：

1. 先梳理业务模型和系统边界
2. 再设计表结构、接口协议和订单状态机
3. 然后实现前后端、支付与库存链路
4. 最后补齐后台、测试、监控和性能优化

这样做出来的小程序店铺，才不仅仅是一个前端入口，而是真正具备交易能力、运营能力和扩展能力的业务系统。