邯郸小程序开发：前后端联调避坑录

做小程序这些年，我越来越觉得前后端联调才是项目真正“见真章”的地方。页面画得再漂亮，接口一对接，问题就全冒出来了。这篇文章不聊虚的，就说说我在邯郸做小程序前后端开发时踩过的坑和总结出的做法，希望能帮到本地正在做小程序的朋友。

一、接口约定要写在代码之前

很多项目一上来就前后端同时开工，结果前端按自己的想象写字段，后端按自己的习惯返回结构，联调时才发现对不上。我的做法是：动手前先花半小时把接口文档定下来，字段名、类型、空值处理、分页参数全部写清楚。

// 统一响应结构
{
  "code": 0,
  "msg": "ok",
  "data": {
    "list": [],
    "total": 0
  }
}

别小看这一步。在邯郸给本地客户做项目，经常是客户中途加需求，如果接口结构一开始就统一，加字段只是增量，不会推倒重来。

二、登录态是前后端最容易扯皮的地方

微信小程序的登录流程是固定的：前端调 wx.login 拿 code，后端换 openid 和 session_key，再签发自己的 token。问题往往出在过期和续期上。

• 前端要统一封装请求方法，token 失效时自动重新登录并重试一次，而不是每个页面各写一套；
• 后端 token 有效期别设置得太短，7 天左右比较合适，同时保留刷新机制；
• session_key 不要下发给前端，解密手机号等敏感操作放在后端做。

之前有个邯郸本地的餐饮客户，用户点餐到一半提示登录失效，体验很差。后来我们把续期逻辑收拢到请求拦截器里，这类投诉基本没有了。

三、数据安全别只靠前端校验

前端做的校验只是提升体验，真正的防线在后端。金额、库存、优惠券这些字段，一定要在后端再算一遍。我见过有项目把价格放在前端提交，结果被人改价下单，损失不小。

原则很简单：前端传来的任何数据都不可信，后端必须按自己的规则重新计算和校验。

另外，小程序端请求要统一走 HTTPS，敏感接口加频率限制，这些在云开发或者自建服务器上都好实现。

四、性能优化要前后端一起看

用户觉得“卡”，原因可能在前端渲染，也可能在后端查询。我的排查顺序是：

1. 先看接口耗时，超过 500ms 的接口重点优化，加索引、减少联表；
2. 再看列表渲染，长列表用分页加载，图片走 CDN 并压缩；
3. 最后看首屏，能缓存的配置数据放本地存储，减少重复请求。

在邯郸做本地生活类小程序时，商家列表接口一开始返回全量数据，首屏要等两秒多。改成分页加字段裁剪后，首屏基本秒开，客户自己也能感觉到差别。

五、本地项目的协作节奏

邯郸的客户很多是实体商家和小团队，需求沟通往往直接面对面。我的经验是：

• 需求确认后出一版原型，让客户在手机上点一遍，比看文档直观；
• 前后端约定好联调时间，别各做各的到最后才合并；
• 上线前留出测试环境，用真实微信账号走一遍完整流程。

我是知码客，专注小程序和 APP 开发，服务邯郸本地客户也接外地项目。前后端开发没有太多玄学，把接口约定、登录态、数据校验这几件事做扎实，项目就稳了一大半。用代码改变生活，这话听着大，但每解决一个联调问题，离它就近一点。