小程序开发架构怎么选

做小程序时间久了会发现，真正决定项目后期维护成本的，往往不是页面写得多漂亮，而是最初那套架构有没有想清楚。我在邯郸做小程序和 APP 开发这些年，接触过不少本地商家的项目，有的一开始只想着“先上线再说”，结果半年后加个会员体系就要大改；也有的从第一天就把分层理顺，后面接支付、接分销、接多门店都很顺。这篇文章就聊聊小程序开发架构里几个关键决策点，以及在不同业务场景下怎么取舍。

先分清三类架构形态

小程序开发架构大致可以分成三种落地形态，选择哪一种取决于业务复杂度和团队规模。

• 纯前端 + 云开发：页面逻辑和数据处理都放在小程序端，后端能力交给云函数和云数据库。适合展示型、预约型、轻电商类项目，起步快，运维成本低。
• 前后端分离：小程序只负责视图与交互，业务逻辑放在独立服务端，通过 HTTPS 接口通信。适合有会员体系、订单流转、多端复用的项目。
• 中台化架构：在前后端分离基础上抽出统一的用户中心、订单中心、商品中心，小程序、H5、APP 共用一套服务。适合连锁品牌或多业务线并行的情况。

在邯郸本地，很多餐饮、零售类客户前期用云开发就能跑通，等门店数量上来、需要和线下收银系统打通时，再逐步把核心业务迁到独立服务端。这种渐进式演进比一开始就上重架构更务实。

分层设计：把变化关在笼子里

不管选哪种形态，代码层面都建议做清晰分层。我通常会把小程序端拆成四层：

• 页面层：只处理渲染和用户事件，不写业务判断。
• 组件层：可复用的 UI 单元，比如商品卡片、地址选择器。
• 服务层：封装接口请求、数据转换、缓存读写。
• 工具层：日期格式化、金额计算、埋点上报等纯函数。

这样拆的好处是，接口地址变了只改服务层，UI 调整只动页面和组件，测试范围可控。很多项目后期难维护，就是因为页面里直接调 wx.request，字段名一改全项目搜索替换。

// services/order.js
import { request } from '../utils/request'

export function createOrder(payload) {
  return request({
    url: '/api/order/create',
    method: 'POST',
    data: payload
  })
}

export function fetchOrderList(params) {
  return request({
    url: '/api/order/list',
    method: 'GET',
    data: params
  })
}

服务层统一收口之后，页面里只关心 createOrder 返回什么，不关心底层是云函数还是 REST 接口，后续迁移成本会低很多。

状态管理与数据流

小程序原生没有全局状态方案，项目一复杂就容易出现页面之间数据不同步。我的建议是按规模分档：

• 页面内状态用 data 管理，不额外引入库。
• 跨页面共享的少量数据，用全局 app.globalData 加简单订阅。
• 购物车、登录态、多步骤表单这类复杂状态，引入轻量状态库或自己写一个基于发布订阅的 store。

关键是别让状态散落在各个页面里。比如用户登录态，统一放在服务层维护，页面只读不写，避免出现“这个页面显示已登录、那个页面还提示登录”的尴尬。

接口与安全边界

小程序端的代码是可见的，所以架构上必须把安全边界划在服务端。几条实践：

• 敏感逻辑（价格计算、库存扣减、优惠券核销）全部放服务端，前端只做展示。
• 接口统一走登录态校验，用 code2Session 换取的 openid 绑定会话，不信任前端传来的用户标识。
• 请求封装里统一处理 token 过期、错误码提示和重试，避免每个页面重复写。

之前有个邯郸本地的连锁门店项目，早期把折扣计算放在前端，结果被用户改参数薅了羊毛。后来把计价逻辑迁到服务端，前端只传商品 ID 和数量，问题才彻底解决。

多端复用与工程化

如果业务同时要做微信小程序、支付宝小程序甚至 APP，架构上要考虑复用。常见做法是把服务层和工具层抽成独立包，页面层按平台各自实现；或者用跨端框架统一编写，再按平台条件编译。取舍点在于：跨端框架能省人力，但遇到平台特有能力时会有适配成本。我的经验是，核心业务逻辑一定抽离，UI 层是否跨端看团队维护能力。

工程化方面，至少要做到：目录结构约定统一、环境配置分离（开发/测试/生产）、提交前做代码检查、构建产物可追溯。这些看起来是小事，但多人协作时能省下大量沟通成本。

写给正在规划项目的你

架构没有标准答案，只有匹配度。一个本地生活服务类小程序，可能云开发加清晰分层就足够；一个要对接 ERP、要做多门店多角色的项目，就得认真设计服务端边界。我在邯郸接触的客户里，做得顺的项目往往不是技术最复杂的，而是架构和当前业务阶段匹配得最好的。

如果你正在规划小程序或 APP，建议先把业务流程画清楚，再决定数据放哪、状态怎么管、接口怎么分层。前期多花两天想架构，后期能少花两个月填坑。