小程序架构怎么搭？北京团队踩过的坑

做小程序这些年，我越来越觉得架构不是画在PPT上的分层图，而是项目跑到第三个月、需求翻了三倍时，你还能不能安心改代码的那口气。知码客在北京做小程序和APP定制，客户从国贸的创业团队到望京的连锁品牌都有，今天不聊虚的，把这套在真实项目里磨出来的架构思路摊开说说。

先想清楚：小程序架构到底在解决什么

很多刚入行的朋友一上来就问“用不用Taro”“要不要上云开发”，其实顺序反了。架构要回答的是三个问题：

• 业务代码怎么分层，改一个需求要动几个文件；
• 数据从哪来、缓存在哪、什么时候失效；
• 多人协作时，谁改哪块不会打架。

这三个问题想明白了，技术选型基本是水到渠成的事。我们在北京接过的项目里，返工最狠的往往不是技术难，而是第一版图省事，页面里直接写请求、直接改data，等到要加登录态、加埋点、加多端适配，整片代码都得重写。

分层：页面只负责“长什么样”

我们现在的默认结构是四层，小项目也照这个来，成本不高但收益明显。

pages/          页面层，只做渲染和事件绑定
services/       业务服务层，组装接口、处理业务规则
api/            接口层，统一请求、鉴权、错误码
utils/          工具层，格式化、校验、常量
store/          状态层，跨页面共享数据

页面里不出现 wx.request，也不出现拼参数、判空、转换字段这类活。页面调 services，services 调 api，数据流单向。好处很直接：接口改了只动 api，业务规则变了只动 services，页面层薄得像张纸，改样式和改逻辑的人互不干扰。

接口层我们统一包一层，把 token 注入、超时重试、错误码映射都收口在这里。北京这边不少客户有多个后端系统，有的还是老接口，这一层就是缓冲带，前端页面完全感知不到后面换了几个服务。

状态管理别过度设计

小程序页面之间共享的数据其实不多，常见的就是登录用户信息、购物车、全局配置。我们的做法是轻量 store：一个模块一个文件，用发布订阅或者直接挂 getApp().globalData 加一层封装，够用就行。真到了需要复杂状态流转的项目，再考虑引入成熟库，别为了架构而架构。

判断标准很简单：如果这份数据只有一个页面用，就放页面里；两个以上页面要同步，才进 store。

云开发还是自建后端

这个问题在北京的客户里问得最多。我的经验是看团队和运维能力：

• 快速验证、预算有限、没有专职后端，云开发上手快，数据库、存储、云函数一套带走；
• 已有后端体系、要做复杂权限和定时任务、数据要落地到自有系统，老老实实走自建接口。

也有混合的：核心业务走自建，活动页、表单收集走云开发，各取所长。关键是接口层要抽象好，后面换实现不至于伤筋动骨。

性能这块，别等上线才想起来

小程序包体积和首屏速度是硬指标。我们习惯在架构阶段就把几件事定下来：分包策略按业务模块切、图片走 CDN 加懒加载、公共组件抽出来避免重复打包、长列表用虚拟列表。北京有客户做本地生活，首页卡片多，一开始没分包，主包顶到快2M，后来重新切分才压下来。这种事早规划省事，晚补救费劲。

写在最后

架构没有标准答案，只有适不适合。知码客一直信“知码识途、匠心铸客”，代码是跟用户沟通的语言，架构就是让这门语言说得清楚、改得动。北京做小程序、APP定制的团队不少，我们不敢说方案最先进，但每一条分层、每一个约定，都是从真实项目里踩出来的。如果你正打算启动一个项目，先把这几层想清楚，后面会轻松很多。