企业官网建设流程全解析

做小程序开发这几年，最常被问到的不是“能不能做”，而是“做一个商城小程序到底要多久”。我习惯把一个商城项目拆成“139模式”来聊：1个核心、3端协同、9大功能模块。这个框架在微信小程序开发里特别实用，配合uni-app这种跨端方案，一套代码就能覆盖用户端、商户端和管理后台。这篇文章就围绕这个模式，把从设计到上线的完整路径讲清楚，适合准备接单或自研商城的开发者参考。

如果你是刚入行的前端，能从中知道一个商城项目应该拆成哪些模块、每一步怎么落地；如果你已经写过不少页面，也可以横向对照一下自己的项目结构，看看是不是踩过“模块粘连”“状态混乱”的坑。我尽量把背后的“为什么”也讲透，不只是贴代码。

1. 139模式是怎么来的：一个商城项目为什么会这样拆

1.1 “139”不是数字游戏，是开发视角的收敛

第一次听到“139”这个叫法，很多同事误以为是某个项目代号。其实它是一套拆解商城小程序的方法：1个核心交易闭环、3个使用端、9个功能模块。这套拆分方式不是凭空想出来的，而是我在接了好几个商城项目之后，被“需求不清、职责不明、排期打架”折腾怕了，才慢慢固定下来的沟通工具。

甲方说“我要做个商城”时，脑子里想的往往是一个能卖货的App效果。“商城”这个词太模糊，如果直接进开发，你会发现需求每天都在变。比如今天说商品分类要三级，明天说分销等级要调整，后天说积分规则也要改。用139模式的好处是，一开始就把范围框住：我们做的是“有交易闭环、有角色区分、有标准模块”的商城，不在这个框架里的需求，先记录后评估。听起来像项目管理，实际上对开发特别友好，因为任务边界清晰了，写代码的人才知道自己到底该做什么。

1.2 1个核心：交易闭环不能断

这里说的“1个核心”，是指商城的主链路必须完整，也就是从“用户看到商品”到“下单支付”，再到“商家发货、用户收货、售后处理”的整个循环。很多小程序看起来功能很多，但用户下单之后找不到订单、支付回调丢失、售后流程断裂，这些都属于核心链路没打通。

开发时我习惯先在文档里画出订单状态流转，而不是先写页面。状态机是这套闭环的骨架：待付款、待发货、待收货、已完成、售后中、已取消，每个状态之间的事件触发条件要写清楚。比如“待付款”超过30分钟自动取消并释放库存，这是通过定时任务实现的，而不是让用户手动取消。把状态机梳理好再写代码，后面接支付、接物流、接售后都会轻松很多。

1.3 3端协同：用户端、商户端、管理后台

一个商城天然有三类角色：买货的消费者、卖货的商家、管全局的平台运营。如果只做一个用户小程序，运营和商家都挤在同一套页面里，权限控制和界面复杂度会拖垮整个项目。所以139模式明确划分出3端：C端小程序给消费者用，商户端给商家管理商品、订单、售后，管理后台给平台方管理用户、数据、配置。

实际项目中，商户端不一定要做成单独的App。预算有限时，可以在同一个微信小程序里通过角色切换实现，用户登录后判断角色，显示不同tabBar和页面。管理后台则建议做成Web，因为运营人员需要批量操作、看数据报表，Web端的效率和操作空间都比小程序好。三端共用同一个后端服务，但接口权限必须分开，至少用token里的角色字段做拦截，不能只靠前端跳转隐藏入口。

1.4 9大功能模块的划分逻辑

9个模块覆盖了商城业务的主要领域：商品、库存、订单、支付、用户、营销、分销、客服、数据。这个划分参考了主流开源商城系统的领域模型，再结合小程序端的交互特点做了裁剪。比如“评价”在很多PC商城是独立模块，但在小程序项目里我建议先放进“商品”模块，有展示和追评能力就够了，不用单独建一套评价后台。

模块化最大的价值是“可独立开发、独立测试、独立排期”。小团队可以并行开发，一人负责商品+库存，一人负责订单+支付，一人负责用户+营销，互相之间只需要约定好接口。后期扩展也方便，比如要给商城加直播，只需要在原有模块旁边新增“直播”模块，不动核心链路。

2. 技术选型：为什么用uni-app做139商城小程序

2.1 跨端方案对比：原生、Taro还是uni-app

做微信小程序开发，绕不开框架选型。原生微信小程序语法上手快，但只有微信端，以后想同步抖音小程序、支付宝小程序、H5，就得再写几套。如果你只服务微信，原生也没问题；但大多数商城项目都希望以后能多端运营，这时候跨端框架就值回票价了。

我在139模式里推荐的是uni-app。它是Vue语法，一次编写可以编译到微信小程序、支付宝小程序、H5、App，生态成熟度在跨端方案里算是比较高的。Taro也做跨端，基于React语法，适合React技术栈的团队。两者都能用，但选uni-app还有一层原因：它跟HBuilderX打包工具深度绑定，云打包、真机调试、插件市场都很方便，尤其是小程序开发者工具之间来回切换，比纯手动配置省事。

这里放一张对比表，方便你根据团队情况选：

2.2 uni-app项目初始化清单与目录结构

用HBuilderX创建uni-app项目时，我建议直接选Vue 3版本，Vue 3的组合式API（setup语法）写商城这种逻辑复杂的业务，比选项式API更清晰，代码复用也方便。

具体初始化步骤如下：

1. 下载安装HBuilderX，新建项目时选择“uni-app”模板，框架选Vue 3。
2. 在manifest.json里配置微信小程序AppID，注意这里需要先注册小程序账号，拿到AppID后才能填。
3. 配置权限声明和隐私保护指引。这个小程序后台有专门入口，不配置的话，用户授权逻辑会被平台拦截。
4. 建立标准的目录结构：pages存放页面，components存放组件，utils存放公共方法，api存放接口请求封装，store存放全局状态（推荐使用Pinia），static存放静态资源。

目录结构看起来简单，但很多新手会犯一个毛病：把接口请求直接写在页面里。一旦多个页面要复用同一个商品查询接口，就得复制粘贴，后续修改接口字段时到处漏改。我坚持所有接口都放api目录，页面里只调方法，这样前后端联调、字段变更都只改一处。

2.3 小程序分包与体积控制

微信小程序主包体积限制是2MB，总包20MB。一个功能齐全的139商城，页面数量很容易超过30个，图片加代码分分钟超限，所以分包是必须做的。

我的做法是：tabBar页面和公共组件放主包，其他模块全部拆到分包。比如营销模块的优惠券列表、秒杀详情，分销模块的推广海报、关系链页面，售后模块的申请退款、退货填单，这些都单独放一个分包。分包配置在pages.json里写，类似这样：

{ "pages": [ "pages/index/index", "pages/category/category", "pages/cart/cart", "pages/user/user" ], "subPackages": [ { "root": "pagesOrder", "pages": [ "order/order-list", "order/order-detail", "order/refund" ] }, { "root": "pagesPromotion", "pages": [ "coupon/coupon-list", "seckill/seckill-list", "share/share-poster" ] } ] }

分包不仅是体积控制，还能提速首屏加载。用户第一次进入小程序时，会先下载主包，分包按需下载。如果你把很多页面塞进主包，首屏加载时间就会变长。

3. 九大模块中关键模块的设计与实现

3.1 商品与库存模块：SKU才是商城的底气

商品模块看着简单，其实是最容易出问题的。很多人早期把商品表设计成一行一个商品，结果卖衣服时遇到颜色、尺码、价格不一样，只能傻眼。正确的做法是引入**SPU（标准产品单元）和SKU（具体库存单元）**的概念。一件T恤是一个SPU，它有白色、黑色两个颜色，有S、M、L三个尺码，白色M码就是一个SKU，库存和价格挂在SKU上，而不是SPU上。

数据库层面至少要有这几张表：商品表（spu）、规格表（sku）、规格属性表（sku_attr）、商品分类表（category）。创建商品时，前端传规格组合，后端根据组合生成所有SKU，并初始化库存。这里有一个关键逻辑：添加购物车时锁定SKU，下单时再次校验库存，支付成功后正式扣减，超时未支付则释放锁定库存。不要在下单前就直接扣减，否则用户取消订单或支付失败，库存还得回补，容易超卖。

3.2 购物车与订单状态机：用户体验的胜负手

购物车在设计上要考虑“游客”和“登录用户”。游客加购时，数据存在本地storage里；用户登录后，可以把本地购物车同步到服务器，避免换设备丢失。我用过最简单的方式是：前端在用户登录后拉取服务端购物车，同时把本地购物车合并上传，合并规则是相同SKU数量相加，取单价较高的覆盖。

订单状态机是整个商城最核心的骨架。我通常用一张状态图把所有转移关系列出来，再写代码。以“待付款”为例，它的操作可以是“取消订单”或“去支付”；“去支付”成功进入“待发货”，失败还在“待付款”；如果超时未支付，定时任务自动取消订单并释放库存。这里要注意，结算金额必须以服务端计算为准，不能信任前端传过来的总价。前端传总价很容易被恶意篡改，服务端要根据当前商品价格、优惠券、运费重新计算。

3.3 微信支付接入：资质与流程

微信支付是商城绕不开的环节，但它的门槛也很明确：小程序必须是企业主体，并且已经申请了微信支付商户号。个人主体无法开通微信支付，只能走其他支付方式，这一点一开始就要跟甲方确认清楚。

支付流程上，标准做法是小程序端通过wx.login拿到code，后端用code换openid，然后后端调用微信支付统一下单接口，拿到prepay_id后生成支付参数返回前端，前端用wx.requestPayment拉起支付面板。支付结果以异步回调为准，不能只看前端成功提示。回调通知需要做验签、校验金额、去重处理，避免重复发货。

我在接支付时踩过几个坑，给你提个醒：微信支付API v3的证书和密钥要放在服务端，一定不能写进小程序代码里；支付回调地址必须是HTTPS，且要在微信支付后台配置好；测试阶段可以用测试商户号，但真机支付建议用真实商户号小额测试，测试环境更容易暴露证书问题。

3.4 用户模块与微信登录

用户模块的核心是微信登录和用户信息管理。wx.login拿到code后，后端向微信的jscode2session接口换取openid和session_key，openid是用户在小程序里的唯一标识，用它作为用户表的主键关联字段。手机号获取需要用户主动点击“手机号快速验证”组件，用户同意后后端通过code换取手机号，而不是直接读取。

这里必须强调一件事：微信平台对用户隐私的管控越来越严。如果你的小程序要获取用户手机号、读取相册、获取位置，必须在“小程序后台-设置-服务内容声明-用户隐私保护指引”中声明对应信息类型，并且在小程序端弹出隐私协议弹窗，用户同意后才能调相关接口。否则真机上会直接拦截调用，表现为“接口闪退”或“没有反应”。很多新手第一次提审失败，就是因为隐私协议没配置。

3.5 营销模块：优惠券、秒杀、拼团的取舍

营销模块是商城做出差异化的地方，但我不建议一次全上。139模式下，我通常先做“基础三件套”：优惠券、限时秒杀、分享裂变。

优惠券要至少建三张表：券模板表（定义面额、使用门槛、有效期）、用户券表（用户领取的实例）、核销记录表。发券方式有主动领取、下单赠送、定向发放。做秒杀时要注意超卖问题，最简单可靠的方式是用数据库乐观锁：扣库存时带上当前库存版本号，更新成功才说明抢到。如果并发很高，再用Redis预扣方案。

分享裂变是很多商城拉新的核心玩法，需要记录用户之间的邀请关系。比如用户A分享小程序给用户B，B打开时带上A的邀请码，后端记录绑定关系。后续可以扩展成分销体系，但这里我想特别提醒：分销玩法要合法合规，宣传语里不要出现“拉人头”“躺赚”等敏感词，分销层级尽量简化，避免踩到平台规则红线。

3.6 数据模块：让运营看得懂

数据模块的价值是让运营人员知道“谁在买、买什么、从哪里来”。初期不需要做大而全的BI系统，先做三块：用户增长趋势、订单金额统计、商品销售排行。

我的建议是从项目第一天就埋点，哪怕只是简单的接口日志。比如每次用户访问首页记录一条日志，下单成功记录source字段，分享出去统计回访情况。后端可以用定时任务每天凌晨汇总前一天数据，写入统计表，管理后台直接查表渲染图表。等数据量大了，再考虑引入专业数据分析平台。不要一上来就搞“实时大屏”，投入产出比很低，而且很容易把开发精力耗在非核心需求上。

4. 开发中常见的坑与排查技巧

4.1 微信小程序审核的隐形红线

139商城涉及支付、用户隐私、商品展示，审核时最容易踩的坑是类目和资质。选择小程序类目时，卖实物商品通常需要“电商平台”类目，并上传营业执照；如果卖食品、化妆品、医疗用品，还需要对应的行业资质。类目选错或资质缺失，审核直接不通过。

另外，很多开发者会在小程序里做“分享得优惠”“邀请好友得红包”，这里要特别小心。微信反对诱导分享，比如“必须分享后才能查看商品”这种设计基本会被判违规。合规的做法是分享行为由用户主动发起，奖励放在用户完成合法行为（如注册、下单）之后，而不是分享动作本身。

4.2 真机调试的常见问题清单

我把这两年遇到的真机问题整理成一张速查表：

真机调试时不要只看模拟器效果。模拟器没有真实的网络链路和权限环境，很多问题只在真机暴露。

4.3 性能优化：首屏打开速度

小程序首屏加载时间是影响用户转化的关键。我实测一个页面如果超过3秒，用户流失率会明显上升。优化首屏我做了这几件事：

第一，主包瘦身。把所有非tabBar页面拆到分包，主包尽量只放首页、导航页和公共组件。第二，首页接口并发控制在5个以内。小程序并发请求上限是6个，超过会排队，导致部分请求超时。我通过合并接口的方式，把首页的“轮播图+公告+分类”整合成一个接口返回。第三，图片必须走CDN并开启懒加载。商品列表页的图片用image的lazy-load属性，首屏只加载可视区域内的图片。第四，对不经常变化的数据进行本地缓存，比如商品分类、首页配置，缓存时间10分钟，二次进入直接显示缓存，体验会流畅很多。

优化后我的一个测试项目首屏从3.1秒降到了1.6秒，这个提升对转化率的影响非常明显。

4.4 数据与接口层面的隐蔽坑

除了明面上的问题和性能，商城项目还有一些埋得比较深的坑：

• 库存扣减要加事务。下单锁定库存、支付成功扣减库存、超时释放库存，这三个操作必须放在数据库事务里执行，否则并发时可能出现负库存。
• 退款流程要独立。提交退款申请后，应该先审核，再调微信支付退款接口，并把退款结果同步到订单状态。退款回调要重复处理，不能因为两次回调就给用户退两次钱。
• 优惠券使用要幂等。同一个订单号只能使用一张券或一组券，要设计好唯一约束，防止重复核销。
• 接口返回字段不要随意删改。版本发布后，老版小程序还在使用，接口直接改字段会导致线上事故。建议接口设计时预留冗余字段，改逻辑时加新字段而不是删老字段。

这些坑很少出现在初见项目里，但都是线上运营时会遇到的真实问题。提前在代码层面避免，比后期补漏省心得多。

5. 从开发到上线的完整流程

5.1 账号与资质准备

开发完成后，上线之前的流程经常被新手低估。首先要确保小程序账号主体和企业资质匹配，然后完成微信认证。微信认证主要是对企业主体真实性审核，认证通过后才能开通微信支付等功能。认证需要准备营业执照、法人身份证、对公银行账户信息，一般提交后几个工作日能完成审核。

注意顺序：先注册小程序并认证，再申请微信支付商户号，再把商户号与小程序AppID绑定。如果反向操作，很容易出现“商户号绑定不了小程序”的问题。

5.2 前后端联调与测试清单

上线前，我会让测试人员照着下面这份清单过一遍，每一步都要真实跑通：

1. 用户注册/登录流程：微信登录、手机号绑定、退出登录。
2. 商品浏览：分类切换、搜索、商品详情、SKU选择、库存不足提示。
3. 购物车：加购、改数量、删商品、清空、合并本地与服务端购物车。
4. 下单支付：正常支付、取消支付、支付超时、支付回调失败重试。
5. 订单状态：商家发货、用户确认收货、申请退款、退款到账。
6. 优惠券：领取、使用门槛校验、到期失效、退款后优惠券退回。
7. 秒杀：并发下单时库存是否正确、是否出现超卖。
8. 权限：游客能看哪些内容，登录用户能操作哪些行为，商家角色能否访问用户后台。
9. 隐私合规：首次进入是否有隐私弹窗，拒绝后是否影响核心功能。

联调的时候一定要用真机测支付，模拟器里的支付环境跟真机不完全一致。支付回调可以本地用内网穿透工具测试，但最终还是要以线上回调为准。

5.3 提审与发布注意事项

提审前，先在开发者工具里上传代码，然后在微信公众平台提交审核。这里有个小技巧：填写审核备注时，把“首次使用请先注册/登录，密码登录功能仅供管理后台使用”等说明写清楚，能减少审核人员误判。审核版本号要用语义化版本，比如1.0.0，方便和后台日志对照。

提审被拒不要慌，按拒绝原因逐条修改。最常见的是“类目与内容不符”和“隐私政策不完整”。前者去调整类目，后者去补充用户隐私保护指引和《隐私政策》页面。改完重新提审，一般再次审核会快一些。

发布后不要立刻全量放量。先用“体验版”或“灰度发布”让一部分用户测试，观察接口错误率和用户反馈，稳定后再全量发布。这里要提醒：发布新版本时，后端接口要兼容旧版小程序，至少保持一个版本的重叠期。

最后再聊一点我个人的习惯

每个项目收尾时我都会回看一遍最初画的状态机，再做一次接口梳理。139模式最大的好处不是省了一个文件命名，而是逼着我在动手前把边界想清楚。很多项目做崩溃不是因为技术难点，而是因为需求模糊、职责交错、回到县太爷式的“哪里缺补哪里”。如果你现在正打算开发一个商城小程序，不妨先按“1个核心、3端协同、9大模块”把文档画出来，排序期的效率会高很多。至于技术栈，我个人建议就用uni-app起步，别在这个阶段纠结原生和框架之争。先把交易闭环跑通，再谈优化和扩展，是商城项目最务实的路径。