先说个结论：别一上来就上uni-app
我去年接了个小程序项目，团队里几个人都说用uni-app开发快，结果做到第三个版本就卡得不行。页面切换要等1秒多，滑动列表掉帧，用户直接在后台骂娘。后来我花了两周把核心页面全部改成原生实现，卡顿率直接从12%降到2.4%。不是说跨端框架不行，而是它帮你包了一层runtime，每次setData都要经过额外的序列化和桥接，性能损耗是实打实的。你如果只做微信小程序，原生才能把你手上的硬件性能榨干。
第一个坑：setData不是让你随便塞的
官方说setData会传输数据到渲染层，但没人告诉你一次传多少合适。我实际测过：在iPhone 11上，一个包含200KB字符串的setData，渲染耗时约300ms；压缩到50KB之后，耗时直接降到60ms。所以我在代码里加了个检测，每次setData之前估算JSON长度，超过80KB就警告。具体步骤：第一，用数据路径，比如this.setData({'list[0].name': 'xxx'})，而不是整个list替换；第二，把频繁变化的字段拆出来独立setData；第三，如果数据只是自己用，不再页面上展示，就存到变量里，别用setData。
分包：主包2M的限制是道硬门槛
微信小程序主包不能超过2M，整个程序所有分包加起来不能超过20M。我第一次做的时候没分包，光echarts和一张图就把主包塞到1.9M，每次打开都要转圈圈。后来我做了分包策略：主包只放tabBar页面和公共组件，其他页面全部扔到分包里。比如“店铺详情”这种二级页面，我放到分packages/shop下，并在app.json里配置preloadRule，提前预加载下一个分包的资源。这样首包下载体积从1.9M降到1.1M，冷启动时间缩短了40%。如果你用构建工具，记得把体积大的库按需引入，别整个echarts全包进来。
实时计算？别用setData熬夜了，试试WXS
有个场景：页面滚动时，我要根据滚动的距离实时改变一个元素的透明度。一开始用bindscroll里setData，每秒触发几十次，页面直接卡成PPT。后来我把这块逻辑用WXS写在wxml里，直接在渲染层计算，根本不经过逻辑层，流畅度立马变成60帧。WXS是小程序里的一个独立语言，可以在视图层运行，适合做这种不需要请求网络的轻量响应。注意WXS里不能调用接口，环境判断也要自己做，但处理这类UI联动场景简直是降维打击。
我的独立观点：跨端是伪需求，除非产品明确要三端同步
很多人做小程序非要上taro或uni-app，理由是以后可以复用代码。但现实是，小程序更新迭代太快，很多新特性跨端框架要等大半年才支持。比如微信的live-player组件，uni-app到现在都还有兼容问题。我现在的原则是：如果你只做微信小程序，老老实实用原生；如果要覆盖支付宝、字节小程序，那就用跨端框架，但一定要预留原生插件的口子，不然遇到性能问题你只能干瞪眼。开发工具方面，原生开发者工具自带的热重载和真机调试比跨端的调试体验好一截，尤其在看渲染层日志的时候。
最后附一个我整理的性能检查清单
每次发布前，按这个清单过一遍：1. 主包体积是否小于1.5M，总包小于15M；2. setData单次数据量是否小于80KB，每秒调用次数是否少于10次；3. 是否用了wxs处理滚动类UI逻辑；4. 图片有没有全部走CDN且压缩到合适的尺寸；5. 页面栈深度有没有超过8层（官方限制10层，但8层就会有内存警告）。这套流程我用了半年，线上小程序基本稳定在2.4%的卡顿率，用户停留时长也提升了18%。希望你能少踩几个坑。