小程序技术：从踩坑到上线，聊聊我的实战经验

做独立开发这几年，我经手的小程序没有三十个也有二十多个了。从最早的“能跑就行”，到现在上线前会认真过一遍性能清单，中间踩的坑真不少。今天不聊虚的，就说说小程序技术这块我实际用下来觉得值得写下来的东西。

一、setData 不是越多越好

刚做小程序那会儿，我习惯把整个 data 对象一把梭更新。页面一复杂，卡得让人想砸键盘。后来才明白，setData 是跨线程通信，数据量越大、频率越高，卡顿越明显。

现在的做法是：

• 只传变化的部分，用路径写法，比如 this.setData({ 'list[2].title': newTitle })
• 频繁触发的场景（滚动、输入）做节流，别每次都 setData
• 不参与渲染的数据挂在 this 上，别塞进 data

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

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

就这一条，我那个列表页的滑动帧率从肉眼可见的掉帧，变成了基本顺滑。

二、分包加载，别等审核被拒才想起来

微信小程序主包有 2MB 限制，这个数字看着不小，但图片、第三方 SDK 一塞就爆。我第一次遇到主包超限时，手忙脚乱地拆代码，结果 tabBar 页面路径配错，白屏了半天。

正确姿势是提前规划：

1. tabBar 页面和首页放主包
2. 低频功能（个人中心、设置、活动页）拆成分包
3. 公共组件和工具函数放主包，分包通过 require 引用

另外记得配 preloadRule，让用户在首页停留时就预下载分包，点进去不用干等。

三、云开发到底值不值得用

这个问题我被问过很多次。我的答案是：看项目阶段。

个人项目、MVP 验证阶段，云开发确实省事。数据库、云函数、存储一条龙，不用买服务器、不用配 HTTPS 证书，一个人就能把前后端全包了。我有个记账类的小工具，纯云开发，从写到上线用了三天。

但项目一旦有并发要求、或者需要复杂的事务处理，云开发的限制就出来了。云函数冷启动、数据库查询条数限制、聚合操作的性能，都是要提前评估的。我的建议是：验证期用云开发快速跑通，业务量上来后该迁就迁，别硬扛。

四、性能优化，上线前必过的清单

我现在每个项目上线前都会过一遍这几项：

• 图片：全部走 CDN，用 WebP，列表图加 lazy-load
• 首屏：骨架屏比 loading 转圈体验好得多
• 长列表：超过 100 条就考虑虚拟列表，别硬渲染
• 定时器：页面 onHide 时清掉，不然切后台还在跑
• 日志：上线前把 console.log 清干净，别问我怎么知道的

还有个小细节：wx.getSystemInfoSync 这类同步 API 别在渲染路径里反复调，缓存一次就够了。

五、关于审核和上线

小程序技术做得再好，审核卡住一样白搭。我吃过一次亏：类目选错，被驳回三次。后来学乖了，提交前先对照官方类目表，涉及用户生成内容的必须配内容安全接口，涉及支付的要把资质准备好。

经验之谈：审核被拒别急着改代码，先看驳回原因对应的规则文档，八成是资质或类目问题，不是技术问题。

写在最后

小程序技术栈不算深，但细节多。真正拉开差距的，往往不是会不会写页面，而是对 setData、分包、云开发边界这些“常识”的理解深度。作为独立开发者，我一个人要兼顾产品、开发、上线，每省下的一次返工，都是实打实的时间。

如果你也在做小程序，欢迎交流踩坑经历。技术这东西，写出来才记得牢。