石家庄小程序开发：前后端实战避坑

在石家庄做小程序这几年，我发现一个挺普遍的现象：很多客户找过来，第一句话是「我要做个商城」，第二句话是「多久能上线」。但真正聊到前后端怎么配合、数据怎么流转，大部分人其实是模糊的。今天就从一线开发的角度，聊聊小程序前后端开发里那些容易踩坑的地方，也算给本地想上车的朋友一点参考。

前后端边界，一开始就要划清楚

小程序不像纯网页，它有个天然的分层：前端跑在微信客户端里，后端跑在你自己的服务器或云开发环境里。很多项目后期返工，根子就在一开始没把边界定好。

• 前端负责：页面渲染、交互状态、本地缓存、登录态维护、调接口。
• 后端负责：业务规则、数据校验、权限判断、订单状态机、支付回调。
• 灰色地带：比如「商品是否可售」这种判断，别只写在前端，后端必须再校验一遍。

我在石家庄桥西区接过一个本地生活类的小程序，客户一开始图快，把库存扣减逻辑写在了前端，结果两个人同时下单直接超卖。后来把扣减挪到后端，用数据库行锁兜底，问题才彻底解决。这类教训，说多了都是泪。

接口设计：别让前端等后端

前后端并行开发的前提是接口先定。我的习惯是先出一份接口文档，字段、类型、错误码都写清楚，前端拿 mock 数据先跑页面，后端按文档实现。

// 统一响应结构，前后端都省心
{
  "code": 0,
  "msg": "ok",
  "data": {
    "list": [],
    "total": 0
  }
}

错误码别用 200 带业务错误，前端判断起来很累。约定好 code: 0 成功，非 0 走统一错误处理，页面上给用户一个能看懂的提示，而不是把后端报错直接抛出去。

登录态与用户体系

微信小程序的登录流程，绕不开 wx.login 拿 code，后端换 openid 和 session_key。这里有个细节：session_key 千万别下发到前端，它应该留在后端，前端只拿你自己签发的 token。

// 前端登录简化流程
wx.login({
  success: (res) => {
    wx.request({
      url: 'https://api.example.com/auth/login',
      method: 'POST',
      data: { code: res.code },
      success: (r) => {
        wx.setStorageSync('token', r.data.data.token)
      }
    })
  }
})

token 过期要有续期机制，别让用户用着用着突然被踢出去。我们一般做双 token，短 token 配长 refresh token，体验会好很多。

云开发还是自建后端？

这是石家庄本地客户问得最多的问题之一。我的建议很直接：

• 需求简单、预算有限、想快速验证：云开发够用，省服务器运维。
• 业务复杂、要对接已有系统、数据敏感：老老实实自建后端。
• 介于两者之间：云开发做前期，后期再迁移，但迁移成本要提前评估。

知码客在给本地客户做方案时，通常会先问清楚业务边界和未来一年的规划，而不是一上来就推最贵的方案。毕竟做小程序不是一锤子买卖，后面还要迭代。

性能与上线前的检查

小程序包体积有 2MB 主包限制，图片尽量走 CDN，分包该拆就拆。上线前重点看几项：首屏加载时间、接口平均响应、有没有把敏感信息打到日志里、支付回调有没有做幂等。

很多问题不是开发阶段暴露的，是上线后第一个真实用户点出来的。所以灰度发布和日志监控，比事后救火重要得多。

最后说句实在话，小程序前后端开发没有那么多玄学，难的是把细节做扎实。石家庄做小程序的公司不少，但真正愿意在接口规范、异常处理、数据安全上花时间的，才是能陪你走远的。知码识途，匠心铸客，每一行代码都该对得起用户的信任。