小程序前后端怎么分工才不返工

做小程序这几年，我发现一个挺普遍的现象：很多人一上来就纠结“前端用什么框架、后端用什么语言”，结果项目做到一半，发现真正卡住的不是技术选型，而是前后端的边界没划清楚。接口改了三版，字段名对不上，登录态各写各的，最后返工的时间比写代码还多。这篇就聊聊我自己踩过的坑，以及现在比较固定的一套做法。

先把“谁负责什么”定下来

小程序的特殊之处在于，它天然是前后端一体的：页面跑在微信里，数据来自你自己的服务端，中间还夹着一层微信的登录体系。所以分工不能照搬 Web 那套，得按数据流来切。

• 前端：页面渲染、交互状态、表单校验、本地缓存、调用 wx.login 拿 code、处理 loading 和错误提示。
• 后端：code 换 openid、签发自己的 token、业务数据读写、权限判断、敏感操作二次校验。
• 灰色地带：字段格式转换、图片上传、分页参数。这些最容易扯皮，我的习惯是统一放在后端做，前端只传原始值。

别小看这条线。我见过一个项目，前端把日期格式化写在了页面里，后端又按另一种格式存库，结果统计报表全错，查了两天才定位到。边界清晰，比什么架构都管用。

接口设计：先定契约再写代码

我的做法是先写一份接口文档，哪怕只是几个 JSON 示例，也比口头约定强。约定三件事：请求方法、参数结构、返回结构。

// 统一返回结构
{
  "code": 0,          // 0 成功，非 0 业务错误
  "msg": "ok",
  "data": {}
}

// 登录接口
POST /api/login
入参: { "code": "wx_code" }
出参: { "token": "xxx", "isNew": true }

返回结构统一之后，前端可以写一个 request 封装，统一处理 token 过期、网络异常、错误 toast。后端也不用每个接口都拼一遍成功失败的壳子。这个约定看着土，但能省掉大量联调时间。

登录态别自己造轮子

微信登录的流程是固定的：前端 wx.login 拿 code，传给后端，后端调 code2Session 换 openid 和 session_key，然后自己签发一个 token 返回给前端。前端把 token 存 storage，每次请求带上。

这里有个坑：session_key 绝对不能下发到前端。有些教程图省事直接返回，等于把解密能力交给了客户端。正确做法是敏感数据解密、手机号获取这类操作全在后端完成。

云开发还是自建后端

这是被问得最多的问题。我的判断标准很简单：

• 项目周期短、团队小、数据量不大，用云开发。云函数 + 云数据库 + 云存储，登录、上传、CRUD 基本开箱即用，省掉服务器运维。
• 需要复杂事务、对接已有系统、有合规或数据落地要求，老老实实自建后端。Node、Java、Go 都行，选团队熟悉的。

云开发不是银弹。它的查询能力和事务支持比传统数据库弱，复杂统计经常要在云函数里手动聚合，数据量上来之后成本和性能都要重新评估。我一般建议：先用云开发快速验证，业务跑通了再考虑迁移，别一开始就上重架构。

几个能立刻用上的小习惯

• 前端请求统一走一个 request 方法，别在页面里到处写 wx.request。
• 后端所有接口都做参数校验，前端校验只是体验，不是安全。
• 分页参数统一用 page 和 pageSize，返回里带上 total，别每个接口一个样。
• 图片上传先传后端换正式 URL，别把临时路径存进数据库，临时路径会过期。
• 开发环境和正式环境用两套配置，域名、appid、数据库都分开，别等上线才发现写死了。

前后端开发最怕的不是技术难，而是“我以为你知道”。把契约写下来，把边界说清楚，剩下的就是体力活。

说到底，小程序前后端开发没有那么玄乎。选型跟着项目走，接口先定后写，登录和上传这类公共逻辑一次做对，后面就顺了。真正拉开差距的，往往是这些不起眼的约定。