小程序开发中容易踩的几个坑

做小程序这几年，踩过的坑比写过的页面还多。有些问题官方文档里写得明明白白，但真正上手时还是会绕进去；有些则是文档没提、社区里也搜不到，只能自己一点点试出来。这篇不讲大道理，就聊聊几个我觉得最值得早点知道的小技巧，尤其是刚接手项目或者准备自己从头写的人，看完能少走点弯路。

一、setData 不是越多越好

刚做小程序那会儿，我习惯把整个 data 对象一股脑丢给 setData，觉得反正框架会帮我处理。结果页面一复杂，滑动就卡，真机上一测，setData 的耗时直接把帧率拉下来了。

后来才养成习惯：只传变化的那一小块。比如列表里某一项的状态变了，就别把整个数组重新 set 一遍，用路径更新的方式：

// 不推荐
this.setData({ list: newList });

// 推荐
this.setData({ [`list[${index}].checked`]: true });

另外，setData 的频率也要控制。像滚动、输入这类高频事件，别每次都直接调，加个节流或者合并到下一帧再更新。数据量大的时候，能放到 wx.createSelectorQuery 或者纯逻辑层处理的，就别往视图层塞。

二、分包和预加载，别等上线才想起来

主包 2MB 的限制，很多人是提交审核被拒了才第一次听说。其实项目一开始就该规划好分包：把不常用的页面、第三方 SDK、大的静态资源都挪到子包里。

配置本身不复杂，在 app.json 里写 subpackages 就行。但有个细节容易被忽略——分包预下载。用户点进某个入口前，提前把对应的子包拉下来，体验会顺很多：

"preloadRule": {
  "pages/index/index": {
    "network": "all",
    "packages": ["shop"]
  }
}

注意 network 设成 all 表示不限网络，但流量敏感的场景最好还是用 wifi，别为了快让用户掏流量。

三、图片和字体，是性能的隐形杀手

小程序里图片加载慢，十有八九不是网络问题，是图太大。我见过一个列表页，每张缩略图都是 200KB 的原图，一屏十几张，首屏直接白屏两秒。

• 列表图统一走 CDN 裁剪参数，按展示尺寸取图，别拿原图硬撑；
• 用 lazy-load 让图片进入视口再加载；
• 占位图用纯色或者极小的 base64，别再用一张大图当 loading；
• 字体文件能子集化就子集化，图标优先用字体图标或者 SVG，少用整包 iconfont。

这些改动单看都不起眼，叠在一起，首屏时间能差出一倍。

四、登录态和缓存，别只存在内存里

很多教程里登录就是拿到 code 换 openid，然后存到全局变量。问题是小程序切后台再回来，或者用户手动杀掉进程，内存里的东西就没了。我的做法是登录态同时落一份到 wx.setStorageSync，启动时先读缓存，再静默刷新，用户基本无感知。

缓存不是万能的，敏感信息别往 storage 里塞。token 这类东西，能放服务端校验的就别只信本地。

还有个小坑：wx.getStorageSync 是同步的，数据大的时候会阻塞。列表缓存这种，考虑用异步版本，或者干脆只存关键字段。

五、真机调试，永远比开发者工具靠谱

开发者工具里跑得飞快，真机上一塌糊涂，这种情况太常见了。工具的性能面板只能参考，真机上的 CPU、内存、网络环境都不一样。

我的习惯是每个功能做完就在真机上过一遍，重点看三件事：首屏时间、滚动是否掉帧、切后台再回来状态对不对。尤其是 iOS 和 Android 的差异，有些样式和 API 行为在两边表现不一样，早发现早改，别攒到提测。

写在最后

小程序开发的门槛不高，但要做好，拼的是这些细枝末节。上面这几条没有什么高深技术，都是被坑出来的经验。如果你正在做自己的第一个小程序，建议从 setData 和分包这两件事开始改，收益最直接。后面再慢慢抠图片、缓存和真机表现，一步一步来，别想着一口吃成胖子。