开发微信小程序这事儿，说起来真是一把辛酸泪。去年秋天接了个电商类的单子，甲方拍着胸脯说"跟做网页差不多"，结果我抱着官方文档啃了三天，连个tabBar都没调明白。后来才悟了，小程序看着像H5，骨子里是套着网页壳子的原生应用，那些自以为熟稔的CSS布局，在真机上分分钟给你表演什么叫"薛定谔的像素"。第一次提交审核被拒，理由是"页面滚动不够流畅"，我盯着代码里那堆未优化的setData，恨不得穿越回去抽自己两巴掌。

踩坑最深的还得是数据通信这块。起初我图省事，所有页面共用一个全局data对象，结果用户A在购物车页面改了个数量，用户B的首页推荐位跟着乱跳。后来学乖了，规规矩矩用事件总线，再复杂的跨页传值也走自定义事件。这里头有个血泪教训：千万别在onLoad里直接拿另一个页面的data，小程序页面栈的存活机制比你想的复杂得多，有时候你以为页面销毁了，其实它还在栈底躺着喘气。现在我的习惯是，所有跨页数据一律过Storage，存之前用JSON.stringify压一遍，取出来再parse，虽然多几行代码，但至少不会半夜接到用户投诉说"购物车长出了别人的东西"。

说到性能优化，那可真是门玄学。有次测试反馈说安卓机切页面白屏两秒，我查了半天发现是某个分包里塞了张3MB的轮播图。小程序对包体积的敏感程度堪比姑娘对体重的执着——主包超过1.5MB就开始给你脸色看，2MB直接罢工。后来我把所有图片都丢到CDN，本地只留压缩到几十KB的占位图，再把页面按功能拆成四五个分包，加载速度肉眼可见地提升了。还有那个setData，刚开始我傻乎乎地整个data对象往上怼，后来才明白它每次传输都要走序列化和渲染管线，改一个字段就传一个字段，别让无关数据跟着陪跑。

组件化这条路，我是走了不少弯路的。最早写页面，一个文件里塞了模板、样式、逻辑三件套，改需求时牵一发而动全身。后来狠下心把轮播、商品卡片、价格标签全拆成自定义组件，虽然初期开发慢了两天，但后面迭代时那个爽快劲儿，简直像从绿皮火车换乘了高铁。这里有个坑得提醒各位：组件间的样式隔离是默认开启的，别想着在父页面用class偷袭子组件内部元素，老老实实给组件加externalClasses，或者传参进去改。还有组件生命周期和页面生命周期的触发顺序，我到现在偶尔还得翻文档确认，反正记住一个原则：组件里别依赖页面onLoad，自己管好自己的事。

审核被拒这事儿，估计每个小程序开发者都经历过。第一次被拒是因为"涉及虚拟支付"，我那个商城明明卖的是实体书；第二次是"类目不符"，说我工具类应用里放了资讯内容；第三次最离谱，说我"诱导分享"——就因为我加了个"邀请好友得优惠券"的按钮。后来我学聪明了，提交前先拿审核指南当圣经翻三遍，尤其是用户隐私那块，什么用户协议、隐私政策、位置授权，一个都不能少。现在我的习惯是，所有涉及用户信息的操作，要么不做，要做就把提示弹窗写得比老太太的裹脚布还啰嗦，宁可让用户嫌烦，也不能让审核员挑刺。

调试真机这事儿，能治好你的所有洁癖。模拟器上跑得丝滑如德芙的代码，一上真机就原形毕露——iOS的橡皮筋效果把页面拽得七零八落，安卓的碎片化机型让你怀疑自己写的是不是同一个程序。我现在办公室抽屉里常备着三台测试机：一台老掉牙的iPhone 6s，一台千元安卓，还有台折叠屏。每次提测前先拿这三台过一遍，能解决百分之八十的线上问题。还有那个调试器，别光看network面板，多看看wxml面板里节点的实际渲染状态，很多时候样式bug都是因为某些属性在特定机型上被忽略了。

说到版本兼容，微信每年两次大版本更新，每次都能整出点新花样。去年他们强推skyline渲染引擎，我为了赶时髦把项目迁过去，结果一堆自定义组件渲染异常，又灰溜溜地改回webview渲染。后来我学乖了，新特性先放着，让子弹飞一会儿，等社区里踩坑的人把雷都趟完了再跟进。不过有两样东西我是一直追新的：rpx单位适配和暗黑模式，这俩是刚需，早适配早省心。

现在再回头看这一年多的小程序开发经历，最大的收获不是技术上的成长，而是明白了"克制"二字。小程序不是网页，不能想怎么炫怎么炫；也不是App，没法随心所欲调系统API。它是个戴着镣铐跳舞的舞者，你得在微信划定的圈子里玩出花来。那些踩过的坑，现在都成了我面试别人时的考题；那些熬夜改bug的夜晚，也变成了跟同行吹牛的谈资。如果你正准备入坑小程序开发，我只想说：别怕踩坑，坑踩多了，路就平了。但记得每次踩完坑，都要把解决方案记下来，因为微信这玩意儿，更新一次版本，可能就把你之前填平的坑又挖开了。