微信小程序开发三年，我踩过的5个坑

做微信小程序开发三年多，接过的项目从几十块的工具类到几万块的商城都有。今天不聊虚的，就说说我踩过的坑，都是真金白银换来的经验。

坑一：以为云开发能省掉后端

刚转微信小程序开发那会儿，看到云开发宣传「不用买服务器、不用写接口」，我直接一个项目全押上去了。结果做到一半发现，云函数的冷启动在低配环境下真的能让你怀疑人生，尤其是首屏要连续调三个云函数的时候，用户看到的白屏时间能到两秒多。

后来我的做法是：云开发适合做轻量业务和快速验证，但涉及复杂查询、定时任务、大文件处理，还是老老实实自己搭后端。云数据库的聚合查询能力也有限，多表关联查起来很别扭。现在我的项目基本都是混合模式：核心业务走自建 API，图片存储、简单表单用云开发。

坑二：分包没规划好，主包超了 2M

这个坑特别常见。一开始所有页面都往主包里塞，等加到二十几个页面，编译直接报主包超限。临时拆分包的时候，发现页面之间的公共组件引用关系一团乱麻。

我的建议是项目一开始就规划好：

• 主包只放 tabBar 页面和登录、首页这类高频入口
• 业务模块按功能拆分包，比如 packageOrder、packageUser
• 公共组件放主包，但要注意别把整个 UI 库都引进来
• 图片资源尽量上 CDN，别打包进代码

分包还有一个细节：分包之间的跳转要用 wx.navigateTo 加完整路径，不能想当然地写相对路径，否则真机上会跳转失败。

坑三：审核被拒的理由千奇百怪

微信小程序开发最磨人的环节不是写代码，是提审。我遇到过因为「类目和内容不符」被拒三次的，也遇到过因为「诱导分享」被拒的——其实就是按钮文案写了个「分享给好友领券」。

审核规则不是写死的文档，是会变的。同一个功能，上个月能过，这个月可能就不行。

我的经验是：涉及用户生成内容、支付、社交裂变的，提前把资质和类目准备好；文案别玩擦边球；提审前用体验版自己走一遍完整流程，特别是授权登录和支付回调。

坑四：性能优化只盯着代码

有次一个客户抱怨小程序卡，我第一反应是查代码，结果发现是首页一次性渲染了 200 多条商品数据，还每张图都是原图。微信小程序开发里，setData 的数据量是性能杀手，超过 1M 就会明显卡顿。

几个实用的优化点：

• 列表用 wx:key，分页加载，别一次全渲染
• 图片走 CDN 加缩放参数，列表图控制在 200px 宽以内
• setData 只传变化的部分，用路径写法比如 this.setData({'list[0].name': 'xx'})
• 长列表考虑用 recycle-view 或者自己写虚拟列表

坑五：低估了「上线后」的工作量

很多独立开发者包括我自己，习惯把「提审通过」当成项目结束。实际上线后才是真正的开始：用户反馈、数据监控、版本迭代、微信基础库升级导致的兼容问题。

我现在每个项目上线前都会做三件事：接入 wx.getRealtimeLogManager 做错误上报；在后台配好性能监控；留一个灰度发布的开关。这些在微信小程序开发里都是现成能力，但很多人不用，等出问题才后悔。

最后说两句

微信小程序开发门槛不高，但要做好，拼的是对细节的耐心。上面这些坑，说到底都是「想当然」造成的——想当然以为云开发万能、想当然以为审核会过、想当然以为上线就完事。多留个心眼，能少走不少弯路。