微信小程序开发写到第四篇了前面几篇聊了环境搭建、基础组件和页面路由今天这篇我想换个角度不按文档顺序讲而是把过去大半年在一线开发里反复碰到的真实问题拿出来复盘。微信小程序这玩意儿上手容易但真正要把体验做好、把坑填平靠的往往是那些文档里不会写清楚的细节。这篇文章我会围绕顶部导航栏适配、请求封装、缓存时间、图片识别、支付合规以及抓包调试这些关键词展开每个点都附上我当时怎么踩坑、怎么解决的思路希望能给正在做小程序或者准备入门的同学一些参考。这篇内容主要适合两类人一类是已经会写基础页面、想进阶处理复杂业务逻辑的开发者另一类是从uniapp或其他跨端框架转过来的前端想弄清楚微信小程序和H5、App到底差异在哪。如果你是纯零基础建议先看完基础语法再回来看这篇不然有些概念会有点跳跃。1. 先认清小程序开发的本质不是单纯“写页面”很多人把小程序当成一个Web页面来做结果做到一半就发现处处受限。小程序虽然长得像网页但它的运行环境是独立的渲染层和逻辑层分离JSCore和WebView之间的通信是有代价的。那些在H5里随手可用的DOM操作在小程序里基本不可用只能通过数据驱动去改变视图。这个认知没建立起来后面写复杂交互时你会非常痛苦。1.1 原生、uniapp、Taro到底怎么选“uniapp开发微信小程序 vs Android/iOS/鸿蒙”这类热词搜索量一直很高说明跨端开发已经成了很多团队的默认选项。我自己的经验是如果团队里后端人力紧张、前端就一两个人项目又有App和小程序两端甚至三端需求那uniapp确实省时间一套Vue语法编译到多端社区生态也成熟。但如果你只是做小程序没有App需求我更推荐原生微信小程序开发。为什么原生小程序的调试工具、性能提示、API覆盖度永远是最及时的。微信每次更新能力原生开发者马上能用但uniapp要等插件适配。举个例子微信出的同层渲染、Skyline渲染引擎这些新特性uniapp支持起来总是慢半拍。而且原生小程序里每个页面都是独立的json、js、wxml、wxss结构清晰出了问题也容易定位。最近鸿蒙那边也在收紧生态如果未来要往鸿蒙靠原生小程序的代码迁移成本不一定比uniapp高到哪去因为鸿蒙也有一套自己的声明式UI。当然这不是说uniapp不行。如果你要兼容H5、小程序、App而且团队Vue技术栈很熟uniapp是务实的选择。关键是别指望“一套代码通吃所有端”就能天下太平每个端都有自己的兼容性坑最终还是要针对微信小程序单独做适配。我的原则很简单项目生命周期长、平台侧重点明确用原生老板要快速试错出多端demo用uniapp。1.2 小程序与传统Web开发的核心差异微信小程序和普通Web最大的差异在于运行机制。Web页面打开就是一口气加载HTML、CSS、JS小程序则是先加载一个包再按需执行每个页面的代码。所以小程序要求主包不能超过2M分包后总包不能超过20M。这就意味着你没法像Web那样肆无忌惮地把几十个第三方库全塞进去得按需引入甚至要自己造轮子。其次是数据管理。Web里你可以用Redux、Vuex做全局状态小程序也有全局数据但页面的setData是同步到视图层的异步操作频繁setData很容易导致页面卡顿。我见过新手直接把一个超大的数组整个setData上去结果渲染掉帧严重。正确的做法是控制setData的频率只传变化的字段必要时用数据监听器。这一点在长列表场景下特别重要后面讲请求封装时我也会再提到。还有一点容易被忽略小程序的每条API几乎都有平台限制。比如支付能力、用户隐私接口、扫码能力等等都需要在小程序后台配置对应的权限甚至要审核通过后才能调用。如果你按照Web的思维直接调接口会发现一键登录都调不起来原因多半是没开通“获取手机号”权限。这些形而下的限制才是真正决定开发效率的地方。2. 那些高频出现的UI与交互细节UI层面的坑往往比业务逻辑更让人抓狂因为看起来就那么几行代码但真机上一跑就变形。比如导航栏高度不同机型、不同系统版本都会变如果你写死一个px那必定会在某台手机上偏移。这一节我挑几个高频问题讲讲。2.1 顶部导航栏高度适配自定义导航到底怎么算“微信小程序顶部导航栏高度”是搜索热词说明这个坑是普遍存在的。小程序默认导航栏高度由系统控制导航栏高度是“状态栏高度 标题栏高度”组成的。状态栏高度可以直接用wx.getSystemInfoSync().statusBarHeight获取但标题栏高度文档里没直接给需要通过menuButton的boundingClientRect来计算。我的适配方案是这样的先调用wx.getMenuButtonBoundingClientRect()拿到胶囊按钮的top和height然后用menuButton.top - statusBarHeight得到标题栏上下留白再用menuButton.height (menuButton.top - statusBarHeight) * 2算出标题栏总高度。这个公式基本可以适配iPhone刘海屏和安卓全面屏。如果你用的是自定义导航记得把页面的navigationStyle设为custom然后给页面根节点加一个占位区域高度就用上面算出来的总高度。对了安卓某些机型的菜单按钮位置可能和iOS不一样所以这套逻辑最好放在app.js里全局计算一次存到globalData里供所有页面使用。我还遇到过一种情况自定义导航下拉刷新时导航栏会跟着页面一起被拉下去视觉上很怪。解决方法是在外层容器上设置position: fixed并把导航栏固定在顶部页面滚动区域单独用一个scroll-view包起来。但这会带来新的问题比如吸顶效果失效需要自己监听滚动位置。总之自定义导航是一个“能用但麻烦”的方案如果你不需要高度定制保留默认导航反而省心。2.2 自定义顶部导航与返回拦截“微信小程序 返回拦截”也是一个被问了无数次的问题。小程序里其实有原生的页面栈管理但默认的navigateBack是不能拦截的。如果你希望在用户点击返回按钮时做一些确认操作比如保存草稿、提示离开大多数人想到的是监听onUnload但onUnload是无条件执行的不给你“取消退出”的机会。我自己用的方案是把返回按钮替换成自定义按钮放弃系统返回手势。比如在自定义导航栏左侧放一个“返回”图标点击后弹Modal让用户选择确认或取消。如果是安卓机自带的物理返回键或侧滑手势可以用onBackPress不对那是App端的微信小程序其实没有统一的接口来拦截系统返回手势只能通过page-container或者web-view等组件间接处理。实测下来最简单的方式是使用wx.enableAlertBeforeUnload这个API从基础库2.12.0开始支持可以在页面卸载前弹出一个系统对话框用户确认后才能离开。虽然不是完全自由的控制但至少能实现“有未保存内容时提醒用户”的效果。我踩过的坑是wx.enableAlertBeforeUnload和自定义导航栏Modal同时存在时会出现双重弹窗体验很差。后来我把自定义返回按钮的Modal去掉了完全依赖系统弹窗反而更统一。所以如果你要拦截返回先评估是需要“选择合适的时机”还是“完全阻止退出”后者在小程序里基本做不到不要硬设计。2.3 单选框与表单交互别被组件坑了“微信小程序单选框”的热度说明大家在表单上没少折腾。原生radio其实是绑定在radio-group下的被选中的值通过bindchange事件回调获取。新手最容易犯的错是给每个radio单独绑定事件结果选中状态混乱。正确姿势是把一组radio放在同一个radio-group里value值设成不同的标识然后监听radio-group的change事件。但这只能满足最简单的需求。如果你要做一个漂亮的单选卡片原生radio样式没法看只能自定义。我的做法是用view模拟可点击区域点击后切换一个>// utils/request.js const baseURL https://api.example.com function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: ${baseURL}${path}, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, timeout: 15000, success(res) { if (res.statusCode 200) { // 业务状态码统一判断 if (res.data.code 0) { resolve(res.data.data) } else if (res.data.code 401) { // token 过期 wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/index }) reject(res.data) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } } else { wx.showToast({ title: 请求失败, icon: none }) reject(res) } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) } module.exports { request }这里几个细节要注意timeout建议显式设置小程序默认是60秒但在移动端网络环境下把超时设成15秒能更快暴露问题。业务状态码的判断不要用HTTP状态码来代替因为服务端有时会返回200但业务实际失败你在后端要定一套自己的code规范。另外Token放在header里比放在参数里更规范但不建议每次请求都从storage读最好启动时读一次放到全局变量里请求时再拼接能省一点I/O开销。还有一点封装的请求函数一定要支持loading参数。我在封装里增加了一个可选配置项showLoading默认false只有特定请求需要时传true。很多人喜欢在请求前统一弹wx.showLoading结果遇到并发请求时某个请求结束就把loading关掉了另请求还在跑画面闪得不行。所以loading一定要按需加载在需要的请求里单独控制或者自己做一个loading计数器。3.3 缓存时间设置让数据不“过期”也不拖累“微信小程序设置缓存时间”这个热词背后是想解决本地存储的更新策略问题。小程序的wx.setStorageSync可以把数据永久存本地但如果你存的是接口数据不设过期时间的话用户看到的永远是旧数据。比如首页banner配错图了你修好了接口但用户手机里的缓存还在展示的还是旧图。我当时用的方案是在存数据的时候同时存一个时间戳和一个有效时长。读取的时候先看时间戳如果距今超过有效时长就返回空重新请求否则直接用缓存。简单说就是手动实现了一个带过期时间的缓存代码也很简单function setCache(key, value, expireSeconds) { const data { value, timestamp: Date.now(), expire: expireSeconds } wx.setStorageSync(key, data) } function getCache(key) { const data wx.getStorageSync(key) if (!data || !data.timestamp) return null if (Date.now() - data.timestamp data.expire * 1000) { wx.removeStorageSync(key) return null } return data.value }这个工具类我放在utils/cache.js里页面里调用getCache判断是否有有效缓存有就直接渲染没有再请求。对于列表页我通常设置5分钟过期详情页1天配置类数据7天。这个时间没有标准答案完全取决于业务对数据实时性的要求。但核心是一定不要无脑永久缓存否则线上改bug的修复速度会追不上老版本的缓存。3.4 热刷新与调试模式真的能做热刷新吗有人搜“微信小程序能做热刷新吗”答案是能但跟Web里的Webpack热更新有区别。开发者工具里编译时如果勾选了“热重载”代码保存后会把改动同步到模拟器页面数据不会丢失这在改样式时效率很高。但真机预览不行真机上是全量编译每次预览都要重新扫码加载。如果你经常调试真机建议用“真机调试2.0”它支持真机上的热重载但只对部分基础库版本有效遇到不支持的机型还是得老老实实重新编译。我在日常开发中的习惯是模拟器上做样式和逻辑调试真机主要跑性能、相机、支付这类依赖硬件的场景。另外开发者工具里按住commandshiftp可以调出命令面板里面有很多快捷键比如“清缓存并编译”这个功能在排解“为什么改了代码没生效”时特别有用因为有时候缓存会有干扰。记住遇到诡异问题时先清缓存。4. 支付与合规别在钱上踩坑这一节提前预警支付是小程序里最需要敬畏的板块因为规则随时会变而且坑特别多。搜“微信小程序虚拟支付 苹果iap退款”的人应该都吃过亏。先说结论微信小程序的虚拟支付在iOS端是受限的。什么意思呢如果你在小程序里卖会员、卖金币这类虚拟商品苹果iOS系统不允许你用微信支付只能用苹果IAP内购苹果还要抽成30%。很多开发者被分走一大块利润所以有时候用户买了虚拟商品后申请退款走的是苹果的退款流程你的服务端需要监听苹果退款的回调及时给用户账号相应处理。这里面最关键的是别把微信支付的逻辑直接套在苹果IAP上否则会出现“钱被苹果收了但你不知道用户到底有没有支付成功”的情况。4.1 微信支付与虚拟支付的基本流程微信小程序的普通支付实物商品、服务类流程是前端调wx.requestPayment需要后端预先调用微信支付统一下单接口拿到paySign等参数。这里有个安全重点支付参数绝对不应该由前端自己生成必须由后端负责签名。很多新手把appid、mch_id直接写在前端代码里等于把商户密钥暴露给所有人这是很严重的违规行为。虚拟支付和普通支付的区别在于渠道。微信小程序里iOS若有虚拟支付需求官方推荐使用“虚拟支付能力”但仅限安卓端iOS要接入Apple IAP。我之前做过一个课程小程序安卓用户买课程走微信支付iOS用户弹出一个半屏弹窗跳转到App Store内购。但App Store审核很严格虚拟商品如果不走IAP小程序和App都可能被拒。所以如果你确实要做虚拟支付建议尽早跟审核沟通或者直接放弃iOS虚拟商品引导iOS用户去官网购买。退款就更麻烦了。微信支付退款有专门接口后端可以主动发起。但苹果IAP的退款是异步推送给开发者的不是用户申请退款后马上通知你。你需要在服务端实现一个Apple退款通知的接收接口当苹果通知有一笔退款时你需要在服务端判断这笔购买对应的账号然后给账号扣减权益或添加相应处理。我踩过坑的是苹果的退款通知会重复发送如果没做幂等处理用户会收到多封退款邮件服务端还把用户的会员权益重复扣减了。所以一定要用transactionId加itemId做唯一键去重。4.2 小程序可以加入支付宝支付渠道吗“微信小程序可以加入支付宝支付渠道吗如何设计”这个问题也有很多人在问。答案是小程序平台不允许你直接调用支付宝SDK因为小程序运行在微信的环境里微信的协议规定了支付渠道只能是微信支付。即使你引入支付宝的JS SDK也会被拦截因为请求域名不允许是支付宝的域名。但如果你一定要支持支付宝有一个变通方案在小程序里生成一个“支付订单”然后展示一个二维码或H5页引导用户用支付宝扫码支付。这个方案需要你自己的后端生成支付宝订单然后小程序弹出一个页面显示二维码或跳转浏览器。不过我要提醒你微信对诱导离开小程序的支付方式管控很严格如果被检测到可能被降权或封禁。所以这个方案只适合合规风险低、用户有主动扫码意愿的场景比如线下扫码支付不适合线上虚拟商品。最稳妥的做法还是直接用微信支付毕竟用户用微信扫码支付的心理成本最低转化率也最高。4.3 年审、域名配置与隐私声明“微信小程序年审”可能很多人不知道怎么回事。小程序注册后每年的认证费用和审核都要续如果你不去年审小程序会被暂停服务。年审的时间线到期前几个月微信会通知你需要登录mp.weixin.qq.com后台提交营业执照或法人信息支付认证费然后等待审核。如果逾期小程序会进入“已冻结”状态用户访问时会提示小程序无法使用。我见过不少开发者忘记了年审导致线上服务突然中断售后电话被打爆所以建议把年审日期设置成日历提醒提前30天开始准备。域名配置也是一大坑。小程序后台要求所有请求的URL都是合法域名必须HTTPS且在后台“开发管理-服务器域名”里配置。如果你在本地调试时不勾选“不校验合法域名”请求直接失败。上线后如果域名没有备案后台也配置不了。这块考验的是后端部署能力很多人前端写得顺畅结果卡在域名备案上一卡就是半个月。所以如果你想快速上线小项目要么提前准备备案域名要么先申请一个开发版的域名白名单做测试。隐私声明是最近一年多特别强调的点。微信官方要求在小程序里设置用户隐私保护指引明确收集哪些信息、用途是什么并在页面通过wx.requirePrivacyAuthorize触发弹窗。如果没做某些涉及隐私的API比如选头像、获取位置、手机号验证会直接报错。尤其像“扫描身份证提取身份证号”这种业务隐私合规是必须过的一关。5. 抓包调试与问题排查实录调试小程序时最常遇到的问题是“为什么真机上接口能通但页面数据不对”或者“网络请求为什么失败”。这时候抓包工具就派上用场了。热词里大量提到“抓包”“Fiddler”“Burp”其实核心目的是看小程序到底请求了什么地址、返回了什么数据。我这里讲一下常规的抓包配置思路以及排查问题的方法。5.1 抓包前的环境准备Fiddler的常规配置Fiddler是Windows上常用的抓包工具用它可以解密HTTPS流量。关键步骤是在Fiddler设置里开启HTTPS解密Tools-Options-HTTPS然后给本机或手机安装Fiddler生成的根证书并将其信任为权威证书。手机端需要把WiFi代理指向电脑的IP和Fiddler端口默认8888。设置完成后Fiddler就能看到手机发出的HTTPS请求内容。注意这里的难点在于让手机信任根证书。安卓7.0以后系统默认不信任用户自己安装的CA证书除非应用在配置里允许用户证书。而微信小程序跑在微信内部即使你信任证书小程序请求时也可能因为证书校验失败而无法发送请求。遇到这种情况一些开发者会去研究“绕过ssl pining”但我必须强调绕过证书校验是违反安全原则的行为可能会触犯法律并破坏用户数据安全。正常开发调试时我们有更好的方式使用微信开发者工具的“不校验合法域名”选项在开发环境直接忽略域名校验不需要抓包工具。真机调试模式下微信开发者工具会显示日志和网络请求情况基本不需要外部抓包。如果一定要看真实环境的数据可以用“真机调试2.0”它的Network面板能看到详细的请求和响应。我平时真机调试时很少动用Fiddler因为开发者工具提供的Network面板已经够用了。它可以看到每个请求的URL、状态码、耗时和响应体。尤其是排查请求返回的数据结构不匹配问题时直接在Network里看响应比抓包更直观。建议你把抓包工具作为最后手段而不是常规手段。5.2 iOS机型网络请求失败率高的排查思路“微信小程序 ios 机型 出现网络请求失败的率很高。web分析6001”这个热词看起来是在iOS机型上遇到了大量网络请求失败。其实“6001”这个数字不是标准的HTTP状态码很可能是你自己后端返回的业务码或者某个代理服务器返回的错误。遇到这种情况先按以下思路排查先看失败发生的时机。如果是App冷启动后立刻发起请求可能是TLS握手阶段失败因为iOS在弱网环境下建立TCP连接需要时间而小程序的timeout如果设得太短就会直接超时。我遇到过iPhone 12在5G网络下打开小程序首页请求失败率超过30%但安卓却正常。后来排查发现问题出在服务器只支持HTTP/1.1而iOS 15以上默认尝试HTTP/2导致某些CDN节点握手失败。后端加了HTTP/2支持后问题就消失了。其次看证书链是否完整。iOS对证书链的完整性要求很高如果你的HTTPS证书是自签的或中间证书缺失安卓可能放行但iOS会直接拒绝。这时候你用开发者工具的Network面板看请求状态会出现“SSL握手失败”之类的错误。解决方法是买正规DV证书并确保部署时把中间证书也配置到服务器上。最后看DNS解析。iOS有时候会遇到DNS解析慢的问题导致请求超时。可以在小程序里启动时用wx.getNetworkType判断当前网络然后对请求做重试机制。但重试要适度不要无限重试建议最多2次每次间隔1秒否则会给服务器造成压力。5.3 常见问题速查表我把平时在小程序开发群里常被问到的问题整理成了一个速查表方便你直接对照排查问题可能原因解决方法chooseavatar:fail api scope is not declared in the privary未在后台申请“头像头像昵称填写”权限在小程序后台“隐私-用户隐私保护指引”中添加对应的接口wx.request请求失败但网页正常未配置合法域名或域名未备案开发时勾选不校验合法域名上线前配置正式域名页面白屏JS报错或组件路径错误查看console使用“清缓存并编译”缓存数据不更新缓存无过期逻辑按上面讲的时间戳缓存方案处理微信支付调不起参数缺失或签名错误检查后端统一下单返回的timeStamp、nonceStr、paySign等字段安卓正常iOS白屏低版本基础库不支持新API在app.json中设置libVersion或用兼容函数判断手机号获取失败未认证或未配置短信签名确认小程序已认证、调用的是getPhoneNumber而不是旧的getPhoneNumber接口这些问题的共性就是报错信息往往不直接需要你耐心去查官方文档和后台配置。很多人只盯着代码看却忽略了权限申请和域名配置结果花了好几个小时。6. 做个能跑的项目从实例到发布光讲理论容易虚最后我拿一个实际的小项目来串一下整个流程。假设我们要做一个“婚礼邀请函”小程序这个题材在热词里也出现了适合用来熟悉整个开发链路。它的需求不复杂展示结婚照片、写下婚礼时间地点、用户可以留言祝福、生成电子邀请函分享给好友。但麻雀虽小五脏俱全够我们练手。6.1 项目结构参考我会把项目按功能模块拆分成四个部分pages/index/index首页展示婚礼主视觉、倒计时。pages/detail/detail详细信息页包括地址、地图导航。pages/message/message留言板用户可以提交祝福。pages/invite/invite生成电子邀请函用canvas把新人照片和文字合成一张图片。这个结构很清晰。首页是用一个swiper滚动相册倒计时功能需要先设置一个婚礼日期然后每秒更新剩余天数。留言板则是最典型的“一个form 一个列表”正好用上前面讲到的单选框其实留言不需要单选框但你可以加一个“关系分类”单选比如朋友/同事/家人正好实践单选框的用法。合成邀请函需要用wx.createCanvasContext绘制图片这是小程序Canvas的老牌技能。整个项目不用后端怎么办可以直接把婚礼信息放本地常量留言可以先存本地用缓存只展示自己的。但如果要多人留言就得引入云开发。微信云开发免费额度够个人项目用不需要自己买服务器。云开发里建一个集合用云函数做接口前端用wx.cloud.callFunction调用比搭传统服务器简单很多。这里我特别推荐新手体验一下云开发它能让你把注意力集中在业务和交互上而不是折腾服务器。6.2 页面搭建的关键细节首页倒计时我踩过一次坑setInterval在小程序里需要清理否则页面加载过多会导致定时器泄漏。正确做法是在onLoad里启动在onUnload里clearInterval。另外倒计时计算要用时间戳差不要用new Date()相减再除以1000因为跨天或时区会有误差。更好的方式是固定一个目标时间戳然后用setInterval每1000ms重新计算target - Date.now()。生成邀请函的Canvas部分要注意图片跨域问题。用户上传的照片或网络图片在drawImage前需要先wx.getImageInfo拿到临时路径否则canvas画不出来。真机上如果图片域名没有配置downloadFile白名单也会失败。所以我会建议用户用wx.chooseMedia选本地图片然后把本地路径转成临时路径一次性绘制。最终分享时用wx.shareAppMessage把邀请函图片带过去接收方点开卡片进入小程序这是一个完整的闭环。我在做这个功能时发现用户最在意的是分享出去的小程序卡片标题和封面图封面图就是canvas生成的那张邀请函。记得在app.json里配置shareAppMessage的imageUrl字段不然分享卡片就是空白。6.3 从开发到上线的完整流程开发完一个页面后别急着提审。先在开发者工具里点“预览”用手机扫码进入体验版确认基本功能没 bug。然后再把代码上传到微信后台设置成体验版。体验版可以分享给开发者和体验成员他们能看到你的页面。体验阶段要注意收集真机反馈特别是一些只有真机能测到的功能比如相机、定位、支付。联调完成、提审前我要提醒你检查这几项域名是否都配置了request、uploadFile、downloadFile域名在后台是分开的。版本号是否提升了每次upload都要在app.json或工具里改一下version。隐私指引是否填写完整如果没有审核可能被驳回。页面是否有空白或死链比如跳转页面路径写错了审核人员会直接点。是否引入违规内容比如诱导分享、强制关注这些都是高危违规行为。提交审核后通常1-2个工作日会有结果。被驳回也不要慌按照驳回原因逐条修改。你可以在后台“开发管理-审核版本”里看到具体驳回说明。我第一次提审就被驳回过原因是“页面中出现了测试数据未删除”改完之后重新提审才通过。所以审核前一定要老老实实把所有测试数据清掉。7. 最后的几个经验与提醒微信小程序开发走到这一步确实不是只靠看文档就能顺风顺水的必须靠实际项目积累细节。我个人在使用过程中的最大体会是小程序是一个半封闭的生态它的优势是用户触达效率极高劣势是平台规则和系统能力随时变化所以开发时要养成看官方更新日志的习惯。微信每年都会新增和废弃一些API如果你一直在用旧接口可能某天突然就不可用了。分享两个我后来才养成的小习惯第一项目里保留一个docs目录专门记录线上踩过的坑和对应的解决方案每次完成一个模块就写几行半年下来就是一份很有价值的避坑手册。第二常用工具组件化比loading、空状态、错误重试都封装成公共组件放在components目录里新页面直接引用能省掉很多重复工作。如果你才刚开始接触小程序不要急着追求炫酷的交互先把“页面-数据-接口”这条链路走通。我从写第一行小程序代码到现在最大的感触是网上有价值的教程不少但信息太碎、更新太慢真正靠谱的永远是官方文档加你自己的实战调试。这篇文章里的方案大部分是我基于常见实践做的整理具体到你的项目可能还要根据实际情况调整。最后再提醒一句不要轻易尝试平台明令禁止的功能比如欺骗式功能、绕过支付、诱导分享等等微信的审核和风控机制很成熟侥幸通过的结果只有被封号一条路。踏踏实实把产品做好把用户体验做顺微信用户的红利足够你吃很久。希望这篇“微信小程序开发四”能帮你在实战路上少走一些弯路。
