微信小程序的学习路径，一上来就扎进API文档，结果被各种配置项和回调函数搞得晕头转向。其实小程序更像一个“被阉割的浏览器”，它的核心矛盾在于：你既要懂前端三件套（HTML/CSS/JS），又要适应它那套独特的双线程架构（渲染层和逻辑层分离）。下面这套路径，会刻意绕过一些“学了但用不上”的坑。

第一阶段：把“伪HTML”玩明白——WXML与WXSS的差异点

别把WXML当HTML写。小程序里没有div、span，只有view、text、image。最反直觉的是text组件——它内部不能嵌套view，否则渲染会乱套。写样式时，WXSS支持大部分CSS3属性，但千万别用通配符选择器，比如* { box-sizing: border-box }，这在小程序里会导致性能崩盘。正确的做法是给每个页面单独写page { box-sizing: border-box }。

实操时，可以拿一个电商详情页练手：用scroll-view做横向滑动图集，swiper做轮播，rich-text渲染富文本内容。注意rich-text里的图片默认不会自适应宽度，必须用img-mode: widthFix属性强制缩放。这个阶段要养成习惯：打开“微信开发者工具”的“真机调试”，因为模拟器里正常的布局，在iPhone SE上经常溢出。

第二阶段：JavaScript在逻辑层的“有限自由”

小程序的JS运行在JSCore（iOS）和V8（安卓）里，但它故意砍掉了window、document对象。写setTimeout做倒计时，结果页面切后台后倒计时停了——因为小程序对setTimeout做了冻结优化。解决方法是改用wx.createOffscreenCanvas或者Worker线程，但更实在的方案是：用wx.setStorageSync记录倒计时截止时间戳，每次页面显示时计算剩余时间。

数据绑定是另一大坑。直接this.data.name = 'new'不会触发视图更新，必须用this.setData({ name: 'new' })。但setData有频率限制（每秒不超过20次），如果连续更新大量字段，建议合并成一次setData。比如购物车批量勾选：

let update = {};
items.forEach((item, index) => { update[`items[${index}].checked`] = true; });
this.setData(update);

这样比循环调setData快10倍以上。

第三阶段：组件化——从“页面碎片”到“功能积木”

小程序的自定义组件和Vue/React的组件有个致命区别：组件内部无法直接修改父组件的data，必须通过triggerEvent抛事件。写一个下拉刷新组件时，会在组件里直接this.triggerEvent('refresh', { time: Date.now() })，但父页面接收事件后，setData更新数据时，组件内部的scroll-view不会自动复位。正确做法是：父页面收到事件后，先重置scroll-view的scroll-top为0，再请求新数据。

组件通信的另一个难点是relations——父组件和子组件之间的联动。比如一个表单组件里包含多个输入框子组件，当用户点击提交时，父组件需要收集所有子组件的值。可以用relations建立链接，子组件通过getRelationNodes获取父组件实例，直接调用父组件方法。但更优雅的方式是：用behavior混入一个共享的store对象，所有组件都从同一个store读写数据，避免层层传递。

第四阶段：API的“暗坑”与性能调优

小程序的API看似简单，但每个接口都有隐藏条件。比如wx.request默认超时时间是60秒，但如果你需要上传大文件，必须改用wx.uploadFile，而且它不支持Content-Type为application/json的请求——服务端必须用multipart/form-data解析。再比如wx.getLocation，在iOS上需要同时请求scope.userLocationBackground权限，否则切后台后定位会失效。

性能优化方面，90%的小程序卡顿都源于setData传输了太多数据。比如一个包含1000条列表的页面，每次下拉刷新都传输全量数据，会导致渲染层崩溃。解决方案是：用wx.createSelectorQuery获取当前滚动位置，只渲染可视区域+上下各50px的缓冲数据。配合recycle-view组件（官方提供），可以轻松实现虚拟列表。注意recycle-view要求每个列表项高度固定，如果高度不固定，可以用intersectionObserver动态计算。

第五阶段：云开发——绕过后端基建的捷径

云开发不是简单的“数据库+存储”，它的云函数本质是Node.js环境，但有个大坑：云函数冷启动时间可能长达3-5秒。避免冷启动的技巧是：把高频调用的云函数设为“固定并发”，或者在云函数里做keep-alive心跳。云数据库的权限系统也容易让人迷惑——openid字段必须显式声明为_openid，否则查询时不会自动过滤用户数据。

实际项目里，推荐用云开发做“用户反馈系统”：用户提交的反馈存到feedback集合，管理员通过cloud.openapi.customerServiceMessage.send推送模板消息。注意模板消息的formId必须从用户点击行为中获取，不能伪造。云存储上传图片时，记得用wx.compressImage压缩到200KB以内，否则上传速度会拖垮用户体验。

第六阶段：发布审核——那些文档没写的“潜规则”

小程序审核最容易被拒的雷区：虚拟支付。如果你的小程序涉及购买课程、电子书、会员，必须走微信的“虚拟支付”接口，但iOS端根本不开放这个能力。折中方案是：iOS用户引导到公众号H5支付，安卓用户走小程序内支付。审核时还要注意wx.getUserProfile的调用时机——必须在用户点击按钮后触发，不能页面加载时自动弹窗。

另一个隐蔽问题是web-view里嵌套的H5页面。如果H5里包含诱导分享的按钮（比如“转发得优惠券”），整个小程序会被封禁。解决方案是：在H5和小程序之间用postMessage通信，所有分享行为由小程序原生组件触发。审核人员会在真机上测试所有页面路径，所以app.json里未声明的页面路径，一定要用navigateToMiniProgram的envVersion参数区分体验版和正式版。

扩展话题：小程序和H5的“混搭”策略

很多团队纠结“全部用小程序”还是“全部用H5”，其实混合方案更实用。比如核心交易流程用小程序原生（加载快、支付体验好），而复杂的图文编辑器、3D展示用web-view加载H5。注意web-view里的H5无法调用小程序的wx.login，需要先在小程序端获取code，通过postMessage传给H5。H5里要避免使用localStorage，因为iOS的WKWebView会在内存不足时清空它，改用wx.setStorageSync更稳妥。

还有一个冷门技巧：用cover-view覆盖在video或map组件上。比如直播页面，弹幕必须用cover-view渲染，否则会被视频层遮挡。但cover-view不支持border-radius，圆角效果需要用cover-image配合透明PNG实现。这些细节，官方文档里往往只字未提。