微信小程序开发实战，技术要点全解析

去年帮朋友改一个电商小程序，光是在页面跳转和参数传递上就折腾了两个通宵。他那个项目用的是最基础的navigateTo，结果页面多了以后，参数一长串堆在url里，又丑又容易出错。后来换成全局变量加事件通道，整个逻辑清爽得像是换了个程序。这件事让我意识到，很多人写小程序，技术栈看着没问题，但一到实战就卡壳，问题往往出在最基础的设计思路上。

微信小程序跟传统H5最大的区别，在于它有一套自己的生命周期和运行环境。你写的代码不是跑在浏览器里，而是跑在微信提供的WebView和JSCore混合环境里。这就带来一个很实际的坑：你在开发工具里调试得好好的，一上真机就出现样式错乱或者接口超时。原因很简单，开发工具的渲染引擎和真机不完全一致，特别是安卓低端机上，CSS的某些属性支持不完整，比如position: sticky在部分机型上就失效。所以实战第一课，别依赖开发工具的自嗨，尽早用真机预览，尤其是覆盖低性能机型。

再说说页面通信。很多初学者习惯用globalData存所有共享数据，但小程序页面有栈的概念，页面销毁后globalData还在，容易造成内存泄漏。更合理的做法是，按业务模块拆分数据存储，能用页面自带data解决的，就别上全局。如果跨页面需要传复杂对象，别直接拼在url里，微信对url长度有限制，而且转义后容易出错。用eventChannel或者直接存到storage，读取时再清理，反而更稳。我见过一个项目，把所有用户信息都塞进globalData，结果用户退出登录后，另外一个页面还读着旧数据，排查了半天才发现是缓存没清。

接口请求这块，很多人的做法是每个页面各自写wx.request，然后复制粘贴一堆回调。这种代码第一眼能跑，但后期维护简直是灾难。你改一个公共请求头，得翻遍所有页面。实战中应该封装一个统一的请求模块，把token注入、错误码拦截、超时处理、loading状态都放在一起。比如遇到401就自动跳登录页，遇到网络错误统一弹toast，这些逻辑收拢到一处，页面代码能缩掉三分之一。我习惯在请求模块里再加一层防重复提交的判断，用flag标记，防止用户连点按钮导致重复下单。

再聊样式布局。小程序天然支持rpx，这个单位是按屏幕宽度750来算的，理论上适配所有机型。但实际操作中，你会发现iPhone的safe area和安卓的虚拟按键会遮住底部导航。解决办法是给底部固定元素加上env(safe-area-inset-bottom)的padding，同时用wx.getSystemInfoSync去判断机型。还有，小程序里flex布局用得比grid多，因为兼容性更好。但flex的嵌套层级一多，性能就下降，特别是列表页里每个item都写一堆嵌套flex，滚动时会明显卡顿。建议列表项能用单层flex解决的，就别套三层。

组件化开发是绕不开的坎。小程序官方提供了自定义组件机制，但很多人还是习惯写一个超长的wxml，把所有UI堆在一起。实战中，组件拆分应该按功能而非视觉来分。比如一个商品卡片，不只是显示图片和价格，它可能还包含加购按钮、库存状态、促销标签。把这些逻辑封装进一个组件，父组件只需要传一个商品对象，内部自己处理事件和展示。这样不仅复用性好，而且改样式只动一处。不过要注意，组件间通信别绕太多层，用triggerEvent向上抛事件，比用selectComponent去操作子组件方法要更符合数据流向。

性能优化这块，最容易被忽略的是setData的滥用。小程序里每次setData都是一次JSON序列化和视图层通信，数据量大或者频率高，页面直接卡死。实战中，我习惯在渲染列表时，先拼好整个数组，一次性setData，而不是循环里挨个set。还有，图片懒加载必须做，用image的lazy-load属性，配合服务端给好宽高比，避免页面滚动时图片跳位。如果你做的是内容型小程序，建议把首屏要用的数据优先加载，剩下的分页请求，别一进来就拉全量。微信对包体积也有限制，主包不能超2M，所以图片资源要尽量用CDN，别本地存一堆大图。

还有一个很多人都踩过的坑，就是小程序的登录态管理。wx.login拿到的code只能换一次openid，而且有效期很短。实战中，应该用code去后端换自定义登录态，存到storage里，每次请求带上。但要注意，这个登录态会过期，所以请求模块里要有静默刷新的机制。我见过一个项目，用户用着用着突然所有接口都报错，就是登录态过期没处理，用户只能杀掉小程序重进。后来加了请求拦截，发现token快过期时先调刷新接口，再重发原请求，体验就好了很多。

聊聊调试和发布。很多人上线前只测了happy path，结果一到真实环境就崩。实战中，建议在开发阶段就接入微信的实时日志和错误监控，把关键操作和异常都打点。小程序后台可以看用户报错，但信息很粗糙，最好自己埋点。发布时用体验版先发给一部分人试，别直接提审正式版。审核也是个玄学，尤其涉及虚拟支付和类目问题，提前在小程序后台看好规则，别等被拒了再改。

说到底，微信小程序开发，技术点其实就那些，但每个点背后都有实战的坑。你踩过一遍，就记住了。小程序这活儿，看着小，做起来深，但摸透了还是挺有成就感的。