石家庄小程序开发：五个少踩坑的实战技巧

在石家庄做小程序这些年，接触过不少本地客户，从北国商城周边的零售商家，到高新区的SaaS团队，再到正定做文旅的小公司。项目做多了会发现，真正拖慢进度、抬高成本的往往不是复杂业务逻辑，而是一些反复出现的小坑。这篇就把我平时压箱底的几个技巧整理出来，都是知码客团队在真实项目里踩过、改过、验证过的。

一、别急着写页面，先把分包和主包想清楚

微信小程序主包上限2MB，这个限制在项目中期最容易爆。很多石家庄的客户一开始只想要个展示+下单，做着做着要加会员、加分销、加直播预约，主包直接顶满，构建失败才发现要重构。

实操建议：从第一天就按业务域拆分包，主包只放 tabBar 页面和公共组件。

// app.json 里提前规划
{
  "pages": ["pages/index/index", "pages/category/index"],
  "subpackages": [
    { "root": "packageMall", "pages": ["pages/detail/detail"] },
    { "root": "packageUser", "pages": ["pages/order/order"] }
  ],
  "preloadRule": {
    "pages/index/index": { "network": "all", "packages": ["packageMall"] }
  }
}

分包预下载配合 preloadRule，用户点进首页时后台已经在拉商城包，体验几乎无感。这个习惯养成了，后面加功能心里不慌。

二、setData 是性能头号杀手，学会做减法

小程序渲染层和逻辑层是分离的，每次 setData 都要跨线程通信。见过一个列表页一次 setData 传了 800 条数据，安卓机直接卡成幻灯片。

• 只传变化的部分，用路径写法：this.setData({ 'list[3].price': 99 })
• 列表分页，一页 10~20 条足够，别一次全量渲染
• 频繁触发的场景（滚动、输入）加节流，输入框用 bindinput 时别每次按键都 setData 回显
• 纯展示、不参与逻辑的数据挂在 this 上，不进 data

我们给石家庄一家做本地生活服务的客户优化过一个订单列表，光是把全量 setData 改成增量更新，首屏渲染时间从 1.8s 降到 600ms 左右，客户当场就说“这钱花得值”。

三、登录态别只靠 wx.login，自己维护一套会话

wx.login 拿到的 code 只能用一次，换 openid 必须走后端。常见错误是前端每次请求都调 login，既慢又容易触发频率限制。

正确姿势：登录后后端下发自定义 token，前端存 storage，请求头带上；token 过期用静默登录续期，用户无感知。这里有个细节，token 续期失败要能自动跳回登录页并保留当前页面路径，否则用户填了一半的表单就没了，这在本地商家的活动报名场景里特别影响转化。

四、云开发能省事，但要认清边界

云开发对中小项目很友好，石家庄不少初创团队用它省掉了服务器运维。但要注意：云函数有冷启动，首次调用可能延迟 1~2 秒；数据库查询单次默认 20 条，要手动分页；复杂统计别硬用聚合，容易超时。

我的判断标准是：业务简单、团队没有后端、上线节奏快，选云开发；有高并发、复杂事务、要对接内部系统，老老实实自建后端。别为了省事把云开发用成“万能胶”，后期迁移成本比一开始搭服务还高。

五、上线前的自检清单

提审被拒是常事，提前自查能少折腾几轮：

1. 类目和实际功能一致，别拿工具类目做电商
2. 所有涉及用户信息的接口有隐私协议弹窗
3. 测试环境域名别混进正式包
4. 分享、支付等敏感能力在真机上走一遍完整流程
5. 体验版先给客户和两三个真实用户试，别自己测完就提审

知码客一直信“知码识途、匠心铸客”。代码是跟用户沟通的语言，写的时候多替用户想一步，上线后少挨一句骂。

这几个技巧谈不上多高深，但每一条都是从返工里换来的。石家庄小程序开发市场这两年越来越卷，拼价格不如拼交付质量。把基础功夫做扎实，客户续约和转介绍自然就来了，这比任何推广都管用。