企业官网建设流程全解析

线上便利店或社区超市要做微信商城小程序，最容易被价格带偏。定制商城系统可能报出几万，SaaS 年费也可能吃掉小店大量利润，于是很多人转向“自己能不能搭”。标题里说的“几百块”，实际上并不是一个精确报价，而是一个方向：如果需求收敛到最小可用的商品浏览、购物车、下单、支付、订单管理闭环，并且自己或团队具备一定开发能力，把认证、域名、服务器这类固定成本控制在较低水平是可能的。

但“低价搭建”不等于绕过平台规则，也不等于随便套一个模板。小程序背后的微信登录、支付回调验签、订单状态一致性、库存扣减、审核合规，才是真正决定项目能不能上线、上线后能不能长期稳定运行的部分。这篇文章会按“需求收敛 -> 技术选型 -> 环境准备 -> 数据设计 -> 前后端实现 -> 支付接入 -> 审核合规 -> 联调排错 -> 上线维护”的顺序，完整梳理一个线上便利店超市类微信商城小程序从零搭建的思路，并给出可复用的表结构、接口逻辑、页面流程和排查清单。

1. 几百块搭建微信商城小程序，钱应该花在哪里

1.1 先把需求砍到最小可用闭环

便利店超市类小程序，最容易犯的错误是一开始就想做会员、拼团、秒杀、优惠券、分销、直播带货全量功能。功能越多，后端状态越复杂，小程序包体积越大，审核风险也越高。用“最小可行交易闭环”来约束，可以先把以下几件事做好：

• 用户能通过微信登录并识别身份。
• 用户能看到门店信息和商品分类、商品列表、商品详情。
• 用户能把商品加入购物车，并能修改数量、选择规格。
• 用户能提交订单，并能选择自提或配送。
• 用户能完成微信支付。
• 商家能收到支付回调并看到订单。
• 商家能修改订单状态，如备货中、配送中、已完成、已退款。

如果这几件事都能跑通，就已经是一个可用的线上便利店商城。拼团、分销、会员储值属于后续扩展，不应该在第一天阻塞上线。这里不是说功能越少越好，而是说第一版的结构要能支持数据演进：商品表、订单表、订单明细表设计得合理，后续增加营销活动会更容易。

1.2 成本构成：认证、域名、服务器

所谓几百块，通常指开发者和团队已经具备人力成本的情况下，固定的基础设施成本。常见支出包括：

如果平台或域名的具体价格发生变化，不影响整体思路。真正影响成本的是：

• 是否自己完成前后端开发，而不是持续采购外部定制。
• 是否采用轻量服务器或云开发，而不是一开始就上高可用集群。
• 是否只保留核心功能，而不是堆砌营销组件。

1.3 技术方案对比：原生小程序、uni-app、云开发

开发微信商城的技术路线不只一种。常见的三种选择如下：

对第一版“几百块搭建微信商城”的目标来说，如果已经有开发团队，原生小程序加自建后端 API 是最容易控制行为细节的方案；如果更想把重心放在业务前端，不想花时间部署 MySQL 和写登录逻辑，云开发是一个低成本起步的选择。这里不把任何方案绝对化为“最好”，实际项目要根据团队成员技术栈和后续规划决定。

2. 开发前环境准备：账号、域名、工具三件事不能乱序

2.1 注册小程序并拿到 AppID

搭建微信商城的前提是有一个已注册的小程序账号。打开微信公众平台，选择“小程序”注册，然后按照主体类型提交资料。主体类型会影响后续能力开放，特别是微信支付的开通，通常要求企业、个体工商户或部分组织类主体才能正常接入。个人主体的小程序功能受限较多，这一点在开发前要弄清楚。

注册后进入小程序管理后台，在“开发管理 -> 开发设置”中可以看到 AppID 和 AppSecret。AppID 用于小程序端初始化，AppSecret 用于后端调用微信接口时换取用户身份。AppSecret 非常重要，只能保存到后端环境变量或密钥管理服务中，不能写进小程序前端代码，否则任何人反编译小程序包都可能拿到密钥，继而冒充服务端调用微信接口。

在小程序开发者工具里新建项目时，需要填入这个 AppID。如果只是本地体验，使用测试号可以跑通基础流程，但涉及到微信支付、真机预览、上线发布，必须使用正式小程序账号的 AppID。

常见坑是团队成员把 project.config.json 里的 appid 留成了 touristappid 或另一个项目的 AppID。表现是小程序可以编译，但登录接口或支付无法回调到当前项目。检查路径是：微信开发者工具右上角“详情 -> 基本信息”中确认当前 AppID，和后端环境变量中的 appid 保持一致。

2.2 服务器域名与 HTTPS 证书配置

微信小程序 wx.request、wx.uploadFile 等接口默认只允许请求 HTTPS 合法域名，并且域名必须在微信公众平台后台配置。开发阶段可以在微信开发者工具中勾选“不校验合法域名”，但这只是开发便利，上线前如果不配置合法域名，真机发布后所有请求都会失败。

域名配置路径通常在小程序后台“开发管理 -> 开发设置 -> 服务器域名”中维护。request 合法域名、uploadFile 合法域名、downloadFile 合法域名需要分别填写。电商项目里商品图片如果从后端接口返回，通常图片域名也要加进 downloadFile 合法域名，否则部分机型加载图片会出现问题。

自建后端时，除了购买域名，还要为域名配置 HTTPS 证书。证书可以来自云厂商的免费证书或统一证书管理服务。一个常见误区是只配置了证书但未让域名完成 ICP 备案。根据国内服务器部署要求，部署在境内服务器的域名一般需要先完成备案，否则 HTTPS 请求也无法正常通过。如果使用香港或境外节点，又有访问速度和合规上的不确定性。

配套的部署结构至少应包含：

• 后端服务监听 443 或通过 Nginx 代理 HTTPS。
• Nginx 配置证书并转发到后端进程。
• MySQL 数据库单独部署或与后端同一台轻量服务器。
• 后端环境变量中写入小程序的 appid、secret 和微信支付商户信息。

2.3 安装微信开发者工具并建立项目骨架

微信开发者工具可以在微信官方文档下载。安装后使用管理员或开发成员微信扫码登录。要注意：如果扫码微信号不是该小程序项目的开发者或管理员，打开项目时会提示“不是开发者”。解决办法是在小程序后台“成员管理”中把当前微信号加入项目成员，同时确保微信开发者工具登录的是同一个微信号。

项目骨架建议分成两块：

miniprogram/ app.js app.json pages/ home/ product-list/ product-detail/ cart/ order-confirm/ order-list/ order-detail/ mine/ utils/ request.js auth.js server/ app.js routes/ controllers/ services/ db/ config/

前端目录是小程序代码，后端是自建服务。如果选择云开发，则后端目录可以替换为云函数目录，但分层思路类似。

小程序 app.json 中需要注册页面路径，并配置 window 标题栏。对于便利店超市场景，首页标题可以按门店品牌命名，比如“XX便利店”，而不是笼统写“首页”。页面标题这种细节在审核时会被人工看到，和实际业务不一致容易引起驳回。

3. 数据设计和后端接口：商城真正复杂的是订单状态

3.1 用 MySQL 表结构支撑便利店场景

线上便利店订单通常会包含商品、规格、数量、价格、配送费用、订单状态、用户信息、门店信息。费用类字段统一使用整数“分”存储，避免浮点数精度问题。示例表结构如下：

CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL, name VARCHAR(100) NOT NULL, spec VARCHAR(100) DEFAULT '', price_cents INT NOT NULL, stock INT NOT NULL DEFAULT 0, image_url VARCHAR(500) DEFAULT '', status TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE cart ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, product_id BIGINT NOT NULL, quantity INT NOT NULL DEFAULT 1, checked TINYINT NOT NULL DEFAULT 1, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL UNIQUE, user_id BIGINT NOT NULL, total_fee_cents INT NOT NULL, freight_fee_cents INT NOT NULL DEFAULT 0, status VARCHAR(20) NOT NULL COMMENT 'CREATED PAID SHIPPING COMPLETED CANCELED REFUNDING REFUNDED', receiver_name VARCHAR(50) NOT NULL, receiver_phone VARCHAR(20) NOT NULL, receiver_address VARCHAR(255) DEFAULT '', take_type VARCHAR(10) NOT NULL COMMENT 'DELIVERY SELF', store_id BIGINT DEFAULT NULL, pay_time DATETIME DEFAULT NULL, finish_time DATETIME DEFAULT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_name VARCHAR(100) NOT NULL, product_spec VARCHAR(100) DEFAULT '', product_image VARCHAR(500) DEFAULT '', price_cents INT NOT NULL, quantity INT NOT NULL );

订单明细表保存商品名称、规格、图片、价格快照，是为了防止商品改价或下架后历史订单无法追溯。这一点特别适合便利店业态，因为生鲜、临期商品经常调整价格。

3.2 登录接口：code 换 openid，会话自己管

小程序登录的通用流程是：

1. 小程序端调用 wx.login 获取临时 code。
2. 小程序端将 code 发送到后端。
3. 后端携带 appid、secret、code 调用微信的 jscode2session 接口。
4. 微信返回 openid 和 session_key。
5. 后端根据 openid 找到或创建用户，并生成自己的登录态 token。
6. token 返回小程序端，后续请求通过 Authorization 请求头发送。

后端示例代码如下：

const axios = require('axios'); async function login(req, res) { const { code } = req.body; const appid = process.env.WX_APPID; const secret = process.env.WX_SECRET; const url = 'https://api.weixin.qq.com/sns/jscode2session' + `?appid=${appid}&secret=${secret}&js_code=${code}&grant_type=authorization_code`; const { data } = await axios.get(url); if (!data.openid) { return res.status(500).json({ message: 'login failed' }); } const user = await findOrCreateUser(data.openid); const token = createToken(user.id); res.json({ token, userInfo: user.publicInfo() }); }

后端拿到 openid 后，不要直接把它作为身份凭证使用。openid 是业务主键，token 才是后续请求的凭证。自己的 token 可以设置有效期，过期后让小程序重新调用 wx.login 换取新 code。

3.3 商品、购物车、下单接口的边界

从商品浏览到下单，接口至少要完成以下几类：

下单接口是后端最需要谨慎处理的接口。前端可以传商品 ID 和数量，但订单金额必须由后端重新计算。常见错误是前端把商品单价、总价都通过 POST 请求传上来，后端直接落库。这样用户只要修改请求参数，就能用 1 分钱买到商品。正确流程是：

// 伪代码，说明思路 async function createOrder(req, res) { const { items, receiver, takeType } = req.body; // 1. 查询购物车项关联的商品 // 2. 后端根据商品当前价格计算 totalFee // 3. 校验并扣减库存，扣减失败则回滚 // 4. 创建 orders 和 order_item // 5. 清空购物车 }

3.4 订单状态机决定了后续所有逻辑

订单状态不能只靠一组字符串来回改，应该有一个明确的状态机。线上便利店订单可以按这个模型流转：

CREATED -> PAID -> SHIPPING -> COMPLETED CREATED -> CANCELED PAID -> REFUNDING -> REFUNDED PAID -> COMPLETED（自提场景，备货完成后直接核销）

自提模式下，可以省略 SHIPPING，从 PAID 变为备货完成后再到 COMPLETED。配送模式下，商家发货后进入 SHIPPING，用户确认收货后进入 COMPLETED。用户必须在订单状态为 PAID 且唯一一次回调时更新状态，避免重复回调导致重复发货或者返利异常。

订单状态机的好处是后端不需要在无数个接口里判断“什么情况能取消”“什么情况能退款”，而是集中在一个模块里定义转换规则。后续接售后、接库存回补，代码逻辑都会清晰很多。

4. 小程序端实现：用户从看到商品到支付成功

4.1 首页、商品分类和列表

便利店超市小程序首页不需要做得非常复杂。比较实用的页面结构是：

• 顶部搜索框，按商品名称搜索。
• 分类导航区，显示饮料、零食、粮油、日用品、生鲜等分类。
• 商品推荐区，按销量或最新上架排序。
• 底部购物车入口，显示当前购物车数量角标。

商品列表页推荐使用“分页加载 + 触发到底加载”，不要一次请求几百个商品。请求封装可以统一放在 utils/request.js 中：

const BASE_URL = 'https://api.example.com'; function request(path, method = 'GET', data = {}) { const token = wx.getStorageSync('token'); return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${path}`, method, data, header: { Authorization: `Bearer ${token}`, 'content-type': 'application/json' }, success(res) { if (res.statusCode === 200) { resolve(res.data); } else if (res.statusCode === 401) { // 登录态失效，重新静默登录 wx.navigateTo({ url: '/pages/login/login' }); reject(res.data); } else { reject(res.data); } }, fail: reject }); }); } module.exports = { request };

小程序登录态过期是常见问题。可以维护一个 promise 队列，避免多个接口同时返回 401 后每个接口都执行一次 wx.login。

4.2 购物车页面与本地缓存取舍

购物车有两种方案：

线上商城建议以后端购物车为准。加入购物车、勾选商品、修改数量都实时同步后端，下单时直接读取后端购物车数据，避免本地数据与商品最新价格不一致。小程序端要把操作结果反馈出来，比如点击“加入购物车”后按钮置灰或避免快速连点，防止重复创建相同请求。

购物车页面要支持以下几种状态：商品已下架、商品库存不足、商品价格变化。这些场景不能只保留“数量设为 1”，还要明确提示用户哪个商品需要重新确认。

4.3 提交订单和 wx.requestPayment

从购物车点击“去结算”进入订单确认页，订单确认页展示商品明细、金额明细、收货地址/自提门店、备注信息。用户点击“提交订单”后，后端创建订单并返回订单号。此时订单还没有支付，状态为 CREATED。用户继续点击“立即支付”，前端调用后端支付接口获取调起支付参数。

微信支付的调起参数不能由小程序端自己拼接，必须由后端使用微信支付商户密钥生成。小程序端拿到参数后调用 wx.requestPayment：

wx.requestPayment({ timeStamp: data.timeStamp, nonceStr: data.nonceStr, package: data.package, // 示例：prepay_id=xxxx signType: data.signType, // v3 场景下常见为 RSA paySign: data.paySign, success() { // 支付结果不在这里更新订单状态 // 以后端支付回调为准 }, fail(err) { // 用户取消支付或其他失败 } });

一个容易踩的坑是：前端 wx.requestPayment 的 success 并不代表订单一定支付成功。用户可能点击支付后，支付结果已经回调到微信服务器，但因为网络原因前端没有收到成功事件。稳妥做法是支付完成后请求一次后端订单详情接口，以后端订单状态为准。

4.4 订单列表和售后入口

订单列表页需要支持按状态筛选：全部、待付款、待发货/待自提、配送中、已完成、退款售后。每个订单卡片都应该显示订单商品缩略图、商品名、实付金额、状态和“去支付/查看详情/确认收货/申请退款”等操作按钮。

便利店场景中，退款的频率通常不如电商高，但必须预留。订单详情页保存售后入口，用户可以在已支付但未收货的订单上发起退款。退款需要后端调用微信支付退款接口，并在退款回调中更新订单状态。第一版如果不想接入微信退款，至少要支持“联系客服”或“商家后台修改退款状态”的线下路径，否则用户遇到问题只能投诉或差评，经营风险会更大。

5. 便利店超市场景的特殊设计：自提、配送、库存和打印

5.1 门店模式和配送/自提切换

便利店超市和纯电商最大的区别在于“门店履约”。一个社区便利店可能同时支持：

• 到店自提：用户下单后到店取货。
• 半小时达配送：由店员或第三方骑手配送。

在订单表里增加 take_type 字段，自提订单要记住用户选择的门店，配送订单要记录收货人姓名、电话、地址和配送费。小程序端地址选择不能只做简单文本框，最好接入微信的收货地址能力或自建地址簿。

门店模式下，配送范围必须有判定逻辑。可以在门店表里维护经纬度和服务半径。第一版可以做一个简化的范围判断：用户地址经过逆地理编码后与门店坐标计算距离，超过配送半径就提示“超出配送范围，请选择自提”。如果距离判断完全交给前端，可以通过修改请求参数绕过，所以较严格的商家会把配送范围判定放到后端。

5.2 商品规格、重量和库存扣减

便利店商品形态很杂：饮料是整瓶，生鲜是称重，日用百货是件。虽然微信商城有商品 SKU 的概念，但便利店第一版不建议过度抽象。可以通过 product 表里的 spec 字段描述“500ml/瓶”或“500g/份”，下单时仍然按件处理，也就是顾客下单的是预包装规格。

库存扣减必须防止超卖。在一个订单包含多个商品时，使用数据库事务和条件更新。示例：

// 伪代码，说明 SQL 思路 const sql = 'UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ?'; const [result] = await db.query(sql, [quantity, productId, quantity]); if (result.affectedRows === 0) { throw new Error('库存不足'); }

不要先 SELECT stock 再 UPDATE stock，这样并发请求可能在读库存时读到旧值。条件更新可以保证只有库存充足时才真正扣减。如果事务中任何一步失败，必须回滚整个下单过程。

5.3 小票打印、标签机和经营提醒

线下便利店接单后需要快速打印小票，否则店员容易漏单。常见的实现方式有两种：

蓝牙打印需要注意微信小程序的蓝牙 API 对 iOS 和安卓的兼容性差异较大。生产环境接入前一定要真机测试不同手机，不能只在开发者工具里验证。

经营提醒同步可以考虑微信订阅消息。用户支付成功后可以向用户发送“订单支付成功通知”，备货完成后发送“取货通知”。这既能提升体验，又能减少用户反复查看订单状态带来的服务器压力。

5.4 管理后台的边界：先做好商品和订单两个模块

很多从零开始的小程序项目，把大量精力花在小程序用户端，却忘记给商家本身留一个管理入口。便利店老板需要可以随时改库存、改价格、查订单。

管理后台第一版建议做在 Web 端，而不是也做成小程序。原因是：

• Web 端更适合表格化操作，打印小票和批量处理订单更顺畅。
• 账号体系可以使用简单的用户名密码加管理员权限，权限范围容易控制。
• 不用走微信小程序审核流程，发布迭代成本更低。

后台模块先做两个：商品管理和订单管理。商品管理支持新增、上下架、改价、改库存；订单管理支持按状态筛选、查看详情、确认备货、确认发货、退款操作。会员、营销可以先不加。

6. 上线审核与安全合规：这一步不能省

6.1 类目、主体和资质要求

便利店超市类小程序提供服务时，需要在小程序后台选择与业务匹配的服务类目。不同类目可能要求提供营业执照范围、食品经营许可证或其他行业资质。实际开发前要核实自己的主体资质是否满足要求，否则开发完了却无法发布，成本损失会非常大。

类目选择的原则是“真实、匹配”。小程序内的商品内容和实际提供的服务必须一致。如果小程序叫“XX便利店”，卖的却全是非门店商品，或类目选择成餐饮服务，审核时很容易被驳回。小程序命名也建议使用与店铺或品牌一致的名字，避免使用“秒杀助手”“全场一折”这类营销感过强但不达意的名称。

6.2 隐私协议和用户信息收集规范

小程序涉及用户手机号、微信昵称、头像、订单地址等信息时，需要在小程序管理后台配置“用户隐私保护指引”，并在小程序中展示隐私政策。页面在收集地址前要明确说明用途。

电商场景最常见的隐私错误是把用户收货地址、手机号等敏感信息广播到前端数据里，或者写入日志未脱敏。后端返回订单数据时，不需要的敏感字段不要返回。图片 URL 要使用 HTTPS，不使用 HTTP 明文。

6.3 支付安全：服务端必须验价

微信支付接入后，最核心的安全原则是：小程序端传来的价格不可信，所有价格必须由服务端按数据库中的商品价格、数量、配送费重新计算。下单、支付、退款回调这三个环节都必须校验订单状态和金额。

微信支付 API v3 的证书和密钥管理建议通过环境变量注入，不要提交到代码仓库。生产环境日志里更不能出现商户密钥、微信支付证书私钥、用户敏感信息。如果使用云开发，也要注意云函数环境变量的权限隔离。

7. 联调验证、常见报错和上线后排查

7.1 本地联调清单

开发阶段，即使本地环境和微信开发者工具能正常跑通，也要按用户真实路径逐项验证。下面是可直接复用的联调清单：

其中支付环节最难模拟。如果使用真实小额支付测试，需要准备测试商品和可退款流程，避免制造无法处理的脏数据。开发者工具中也可以看到部分支付调试能力，但线上真实支付参数以真机测试为准。

7.2 常见报错和排查链路

开发过程中最容易遇到的问题，和它们的排查顺序如下：

以上排查顺序遵循一个原则：先查环境配置，再查请求参数，再查后端逻辑，最后再怀疑框架本身的问题。不要一上来就改代码。

7.3 线上日志、监控和版本回滚

上线后不能只看小程序页面是否正常。后端至少要记录以下日志：

• 登录请求日志，用于排查异常登录。
• 商品查询慢日志，用于分析接口性能。
• 下单事务日志，用于定位金额不一致、库存不足问题。
• 支付回调原始通知和验签结果，这是排查支付异常的关键证据。
• 退款记录日志，用于对账。

小程序版本更新时也存在风险。新版本发布后如果发现严重 Bug，可以在微信公众平台中回退到之前的线上版本。因此发布前要把版本号管理清楚，不要反复覆盖线上版本导致无法回退。

后端接口本身也要做好版本管理。常见做法是保留上一版本接口的兼容支持，在迁移完成后再下线旧接口。对便利店小店而言，回滚速度比功能迭代速度更重要，所以发布前要保存当前可用版本的备份信息。

8. 降低维护成本的操作建议

8.1 发布前检查清单

上线前把下面这份清单过一遍，可以减少大量返工：

• 小程序名称、头像、简介和实际经营范围一致。
• 服务类目与营业执照、行业资质匹配。
• 后台已配置服务器域名，且域名证书有效。
• 小程序隐私保护指引已填写，隐私政策页面可以正常打开。
• 后端环境变量中的 appid 和 secret 使用正式值，且不包含在 git 仓库中。
• 微信支付商户号已关联到小程序，证书和 API v3 密钥配置正确。
• 商品图片全部使用 HTTPS。
• 后端接口已校验登录态，敏感数据不返回不必要内容。
• 下单金额由服务端计算，支付回调和退款回调都做了验签和幂等处理。
• 订单和商品表有索引，订单明细有商品快照。
• 自提和配送流程在真机上完整验证。
• 测试数据已清理，所有“测试商品”和“测试订单”已下架。
• 管理后台能正常修改订单状态。
• 日志服务或文件备份已配置，数据库有自动备份策略。

8.2 预算紧张时可以这样省

如果第一年预算很紧张，可以从以下方面控制：

• 域名可以选择普通常规后缀，但不要购买冷门后缀，通常价格差异体现在续费上。
• 后端可以先用轻量应用服务器，而不是云数据库实例和服务器分开买。
• 商品图片存储在对象存储中，只在上传或修改商品时产生低频读写费用，比放服务器本地磁盘更灵活。
• 营销短信可以不用，优先使用微信订阅消息触达用户。
• UI 组件优先使用微信官方组件基础库能力，不引入太重的第三方框架。

需要省的不是数据库表设计、不信任前端金额、支付回调验签这类安全逻辑，省的是服务器配置和营销资源。安全性和数据一致性不能因为预算小就牺牲。

8.3 从第一版到长期运营的学习路径

如果读者对微信商城底层开发还不熟悉，不要一上来就写支付和售后。建议按以下路径练习：

1. 先搭一个简单的商品列表小程序，请求自建后端返回 JSON。
2. 打通微信登录，理解 code2session 和 token 的关系。
3. 用本地数据模拟购物车，再迁移到后端购物车。
4. 完成下单接口，重点处理库存扣减和状态机。
5. 申请测试商户号，在沙箱环境中完成支付回调。
6. 接入退款，并验证退款回调。
7. 再加上门店自提、配送、库存预警、订阅消息等功能。

这个过程看起来慢，但每一层都是后面稳定运行的基础。几百块能搭起第一版，意味着把预算花在了最关键的固定成本上；真正决定小程序能不能持续运营的，是下单一致性、支付安全和售后处理这些开发基本功。先跑通最小交易闭环，再逐步叠加门店和营销能力，是便利店超市类小程序最稳妥的落地方式。