小程序架构怎么搭才不返工

做小程序这几年，我踩过最大的坑不是某个 API 用错了，而是项目一开始架构没想清楚，做到一半发现页面之间数据乱飞、改一个功能牵动五个地方。后来我把架构这件事前置，返工率明显下来了。这篇就聊聊我自己在用的那套结构，不追求高大上，只求能扛住需求变化。

先想清楚：小程序和普通 Web 差在哪

很多人拿写网页的习惯直接套小程序，结果处处别扭。核心差异有三点：

• 逻辑层和视图层是分开的，setData 是唯一的通信桥，数据量一大就卡。
• 页面栈有上限（默认 10 层），跳转方式选错很容易把栈撑爆。
• 包体积有硬限制，主包 2MB、总包 20MB，不提前规划分包，后期只能硬删代码。

所以架构设计的第一目标，不是代码多优雅，而是控制数据流和体积。

目录结构：按职责分，别按页面堆

我见过太多项目把所有东西塞进 pages 里，一个页面文件夹里既有请求又有工具函数。我现在的习惯是这样：

miniprogram/
  pages/          // 只放页面和它的 wxml/wxss
  components/     // 通用组件，按功能命名
  services/       // 接口请求，一个业务模块一个文件
  store/          // 全局状态
  utils/          // 纯函数工具
  config/         // 环境配置、常量
  subpackages/    // 分包业务

关键是 services 和 store 单独抽出来。页面里不直接写 wx.request，而是调用 service 方法；不直接改全局变量，而是走 store 的 action。这样以后换接口域名、加缓存、做 mock，都只改一处。

数据流：别让页面自己管全局状态

小程序官方没有强制状态管理，小项目用 getApp().globalData 能跑，但一旦涉及多页面共享（比如登录态、购物车），就会变成谁都能改、谁都不知道谁改的烂摊子。

我的做法是写一个极简的 store，几十行就够：

const store = {
  state: { userInfo: null, cart: [] },
  listeners: [],
  setState(patch) {
    this.state = { ...this.state, ...patch };
    this.listeners.forEach(fn => fn(this.state));
  },
  subscribe(fn) {
    this.listeners.push(fn);
    return () => {
      this.listeners = this.listeners.filter(f => f !== fn);
    };
  }
};
module.exports = store;

页面在 onLoad 里订阅，onUnload 里取消订阅。数据变了页面自己更新，不用再靠事件总线到处传。这套东西不引入任何依赖，维护成本几乎为零。

分包与首屏：体积是硬约束

主包只放 tabBar 页面和登录、首页这类高频入口，其余业务全部丢进分包。分包策略按业务域切，比如 order、user、activity 各一个分包，别按页面数量平均切，否则跨包跳转的公共依赖会重复打包。

另外两个细节：

• 把不常变的大图、字体放 CDN，别塞进包里。
• 用「分包预下载」在首页空闲时预加载用户大概率要进的包，体验会顺很多。

setData 的性能红线

setData 的耗时和传输数据量正相关。我的经验是单次别超过 100KB，列表分页加载，长列表用虚拟列表。还有一个容易忽略的点：不要 setData 整个对象，用路径更新：

// 差：整个 list 重新传一遍
this.setData({ list: newList });

// 好：只更新变化的那一项
this.setData({ [`list[${index}].status`]: 1 });

频繁触发的场景（滚动、输入）记得加节流，不然低端机上肉眼可见地掉帧。

云开发要不要用

如果你是独立开发者或小团队，云开发能省掉服务器和运维，登录、数据库、云函数一套搞定，起步非常快。但它的冷启动和查询限制在复杂业务里会碰到天花板。我的判断标准是：业务以读为主、并发不高、不想管服务器，就用云开发；涉及复杂事务、高频写入或需要和已有后端打通，还是老老实实自建服务。架构上把请求层抽象好，两者切换的成本其实不大。

最后一句

小程序架构没有标准答案，但有一条底线：让改动只发生在一个地方。数据流收口、请求收口、公共逻辑收口，做到这三点，需求再怎么变，你也不至于推倒重来。