北京小程序前后端开发实战笔记

最近接连交付了三个北京本地的小程序项目，一个是朝阳区的连锁烘焙品牌，一个是海淀的社区健身工作室，还有一个是通州的少儿美术培训机构。三个项目规模都不大，但前后端配合的坑踩得挺全。这篇就把我在北京做小程序前后端开发的一些实战经验整理出来，给准备动手或正在踩坑的朋友参考。

先想清楚：后端到底放哪

很多北京本地的中小客户一开始都会问：「我这小程序需要自己买服务器吗？」我的回答通常是——看业务。如果只是展示、预约、简单表单，云开发（微信云开发 / 腾讯云开发）基本够用，省去了服务器运维、备案、域名这些麻烦事，特别适合刚起步的本地商家。

但一旦涉及多端共用数据（比如小程序 + 公众号 + 后台管理系统）、复杂权限、或者要对接客户已有的 ERP，那就老老实实上自建后端。我在海淀那个健身项目里就吃过亏：一开始图省事用云开发，后来客户要接自己的会员系统，数据迁移折腾了整整一周。教训是：业务边界没想清楚之前，别急着选技术栈。

前后端接口约定，比写代码更重要

前后端分离开发，最容易出问题的不是技术，是沟通。我的习惯是开工前先拉一个接口文档，字段名、类型、错误码全部写死，双方按文档来。下面是一个典型的预约接口约定示例：

POST /api/appointment/create
{
  "openid": "string",
  "serviceId": 1001,
  "appointDate": "2024-06-01",
  "timeSlot": "14:00-15:00",
  "remark": ""
}

// 统一返回结构
{
  "code": 0,
  "msg": "ok",
  "data": { "orderId": "A20240601001" }
}

约定好之后，前端可以先 mock 数据跑通页面，后端同步写逻辑，最后联调时基本一次过。这一点在北京这种节奏快的项目里尤其重要，客户催得紧，返工成本太高。

登录态与用户体系

小程序端用 wx.login 拿 code，后端换 openid，再签发自己的 token。这里有个细节：不要把 openid 直接暴露给前端当身份凭证，一定要走服务端 session 或 JWT。我在通州那个美术培训项目里，就见过同行直接把 openid 塞进请求头，安全性基本为零。

// 小程序端登录
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)
      }
    })
  }
})

北京本地场景的几个坑

• 网络环境复杂：客户在写字楼、商场、地下车库都可能用小程序，弱网下的加载态、重试机制一定要做，别假设用户永远 4G 满格。
• 支付与发票：北京的企业客户对开票需求很敏感，支付成功后最好预留发票申请入口，哪怕先做成人工处理。
• 合规：涉及用户信息收集，隐私协议、授权弹窗要规范，尤其是面向学校、培训机构的小程序，家长很在意这个。
• 审核周期：北京地区类目审核有时会慢一些，提前准备好资质材料，别卡在上线前一天才发现类目不对。

性能优化：别让小程序的「快」变成「慢」

前后端一起优化才有效果。前端控制首屏请求数量，图片走 CDN 并压缩；后端接口做字段裁剪，列表接口别把详情字段全返回。我在烘焙项目里把首页接口从 300KB 压到 80KB，首屏时间直接少了一半。另外，setData 的频率要控制，列表滚动时别每次都全量更新。

写在最后

知码客一直相信「知码识途、匠心铸客」，每一行代码都是和用户沟通的语言。北京这块市场客户要求高、节奏快，但也正因为如此，把前后端的基本功打扎实，反而能走得更稳。如果你正在北京做小程序开发，或者准备找团队定制开发，希望这些踩坑记录能帮你少走点弯路。