小程序跳转API从小程序跳小程序到App互通的实用手册过去一年多我一直在折腾小程序生态里的各种跳转能力。别看“跳转”两个字听起来简单真正做起来才发现里有门道——小程序跳小程序、小程序跳App、H5页面跳小程序、甚至从短信和二维码直接唤起小程序每一类跳转都有自己的一套规则和边界。我见过很多开发者在文档里翻半天找不到头绪或者照着示例写完了却在实际机型上跳不动。这篇文章就把我实测过的跳转API和周边方案梳理一遍希望能帮打算接跳转功能的团队少走些弯路。1. 跳转需求全景图先搞清楚你要解决哪种跳转先说个我自己的例子。之前做某个社区类小程序用户分享内容到微信后朋友点开链接进入小程序这个时候需要从分享卡片直接落到内容详情页。后来又增加了跨小程序导流的业务场景——从A小程序点个按钮跳到B小程序完成联合登录。再后来运营提出要能从公众号菜单直接拉起小程序指定页面。这几个需求看似都是“跳转”但底层用的API完全不同遇到的问题也各自不同。1.1 跳转能力的四种典型场景我按实际业务场景把跳转需求分成四类每个团队立项的时候应该先对号入座确定自己到底要解决哪一类。页面间跳转小程序内部的页面导航用户点击、支付完成回调、表单提交后跳页。核心API是wx.navigateTo、wx.redirectTo、wx.switchTab、wx.reLaunch、wx.navigateBack这一组。小程序间跳转从小程序A跳到小程序B常用于联合运营、互相导流、跨团队合作。核心API是wx.navigateToMiniProgram。从微信外部场景拉起小程序包括公众号菜单、H5页面、扫码、短信链接、App分享卡片。核心机制是URL Scheme和URL Link微信内部则走开放标签。原生App跳小程序自家App向小程序导流需要SDK级别的跳转能力常见于电商和工具类产品。这四类场景不是互相替代的关系而是不同入口组合成完整的跳转闭环。我见过一些团队一开始只做了内部页面跳转后来运营要跨小程序投放才发现还有单独的API要做也见过团队一开始直接上URL Scheme结果发现分享到朋友圈不支持又回来补URL Link。所以动工之前先把整个跳转矩阵画清楚能省掉后期返工。1.2 跳转API的总体选型逻辑选型逻辑其实一句话就能说清先确认跳转的出发地和目的地分别在哪里再查对应的官方通道。出发地如果是小程序内部优先用内置导航API出发地如果是H5页面就要区分是微信内置浏览器还是外部浏览器出发地如果是原生App需要接入开放平台的SDK。这里有一个很重要的认知我踩过坑之后才彻底明白小程序不是一个可以自由跳转的开放网络而是一个受到平台规则约束的闭环。每一个跳转通道都有域名校验、AppID白名单、参数长度限制、场景值区分等等。所谓“跳转API怎么用”这门功课一半是学API签名另一半是搞懂这些约束是怎么配合的。下文我会按实际开发顺序逐步拆解先讲小程序内部的页面导航再讲跨小程序跳转然后是我觉得最容易被坑的H5与App互相拉起最后是各类跳转失败时我总结的排查思路。每个模块都会给到可以直接抄走的代码示例和参数说明。2. 小程序内部页面导航页面栈的进与退小程序内部跳转是所有跳转能力的地基。虽然看起来只是几个API名称的区别但页面栈的机制决定了你按哪个API跳、跳完之后用户按返回键能回到哪里。不夸张地说做了两年小程序开发我见过因为页面栈没理清导致用户点返回直接退出的线上事故。2.1 五个核心导航API到底该怎么选打开官方文档你会看到五个导航API摆在一起wx.navigateTo、wx.redirectTo、wx.switchTab、wx.reLaunch、wx.navigateBack。很多新手以为它们只是“跳转页面”的一种写法的五种变体其实它们管理页面栈的方式完全不一样。wx.navigateTo保留当前页面跳转到应用内的某个页面页面栈会叠加一层。适用于详情页、子页面这类用户很可能要返回的场景。wx.redirectTo关闭当前页面跳转到应用内的某个页面页面栈不叠加。适用于登录态校验后重定向、表单提交后的结果页这类不需要回退的场景。wx.switchTab跳转到TabBar页面并关闭其他非TabBar页面。只能跳转到app.json里tabBar.list中声明过的页面。wx.reLaunch关闭所有页面打开到应用内的某个页面。适用于从深层子页面一键回到首页或者切换用户身份后重新初始化整个界面。wx.navigateBack关闭当前页面返回上一页面或多级页面。可通过delta参数指定返回层级delta为1时返回上一页。如果你之前用习惯了Web开发里的location.href到这里要特别注意小程序导航API不是URL跳转而是页面栈操作。navigateTo跳得越多栈越深到了第十层就会触发“页面栈已满”的提示。这是官方限制页面栈最多十层。一旦超过navigateTo会直接失败用户点按钮没有反应。2.2 按场景匹配导航API的决策流程实际开发时拿到一个需求先别急着写wx.navigateTo花十秒钟想清楚“用户从哪来要到哪里去需不需要原路返回”。我之前项目的首页有一个每日签到入口签到流程是首页 - 签到规则页 - 签到页 - 签到成功页。当时的PRD写得很模糊只说“签到成功后展示结果”。第一次实现的时候我默认用了navigateTo一路压栈结果用户签到成功后连点三次返回一层一层倒回去体验非常割裂。后面改成这样首页进入签到规则页用navigateTo规则页确认后redirectTo到签到页签到完成后再redirectTo到成功页。这样用户从签到成功页按返回直接回到首页不会路过已经消费完的中间页面。再举一个典型的电商场景用户从商品列表进入详情页加入购物车之后跳转购物车页面。这里购物车页应该用switchTab如果购物车是Tab页或者用redirectTo如果购物车是普通页面。如果用navigateTo用户从购物车返回时回到的还是刚才的商品详情页而不是商品列表很容易造成困惑。2.3 页面间参数传递与数据同步跳转API的关键参数主要靠url字段携带。navigateTo和redirectTo的url支持拼接查询参数例如wx.navigateTo({ url: /pages/detail/detail?id123fromhomepage });接收端在目标页面的onLoad(options)里拿参数Page({ onLoad(options) { const { id, from } options; console.log(接收到的参数, id, from); } });这里有几个容易踩的细节。参数值会被URL解码一次如果带了特殊字符如、、?、%一定要提前做encodeURIComponent编码否则参数会被截断或解析错乱。我见过一个真实案例运营配置的商品名称里带了“AB”这种字符串开发时没做编码结果详情页拿到的参数变成了“A”商品信息直接查不到。另外URL参数有长度限制太长就建议改用全局变量或者页面间通信的存储方案。跨页面数据同步也是个隐藏问题。页面A修改了用户昵称navigateBack回到页面BB页面的显示却还是旧昵称。这不是跳转API本身的问题而是页面数据没有刷新。常规解法是在B页面的onShow生命周期里重新拉数据。页面栈的叠加和退栈决定了onLoad只会在页面首次创建时执行而onShow每次回到前台都会触发。所以凡是上一页可能修改数据再返回的场景记得把数据刷新逻辑放到onShow里。3. 跨小程序跳转navigateToMiniProgram的参数与边界小程序之间导流是一个敏感又有趣的话题。平台对这个通道管控很严但一旦跑通效果也立竿见影。我之前参与过一个导流合作项目用户从内容小程序里看到一个工具点一下直达工具小程序完成操作再一键返回内容小程序继续浏览。这个体验做好了转化率能有明显提升。3.1 从A小程序跳B小程序的完整流程wx.navigateToMiniProgram是跨小程序跳转的核心API。基础写法wx.navigateToMiniProgram({ appId: 目标小程序的AppID, path: pages/index/index?id123, extraData: { token: 用户token, goodsId: goods_001 }, success() { console.log(跳转成功); }, fail(err) { console.log(跳转失败, err); } });官方文档里的字段不多但每个都有讲究。path可以不传不传则落到目标小程序的首页extraData是以对象形式传给对方的数据对方在App.onLaunch或者Page.onLoad里通过wx.getLaunchOptionsSync()或options参数获取。这里最容易被忽略的是目标小程序必须在后台被添加到跳转白名单里。也就是说A跳BB的运营者需要在后台配置允许来自A的跳转。这个配置不是实时的配置完成后有一定的生效周期我遇到过配置完之后跳转仍然失败过了差不多半小时才稳定的情况。跳转之前还建议先调一次wx.checkIsOpenApplet确认目标小程序确实可用wx.checkIsOpenApplet({ appId: 目标小程序的AppID, success(res) { if (res.checkResult) { // 可以放心跳转 } } });不过需要留意这个检查接口的返回只是一个预判结果不代表跳转一定成功。正式跳转之后还是要处理fail回调。3.2 跨小程序跳转的限制清单做这类跳转之前必须把限制搞清楚免得开发到一半被告知方案不行。我整理了一份实测过的限制清单目标AppID必须真实存在且已发布开发版、体验版也能跳转到但需要加入开发者或体验成员否则会提示无权限。目标小程序需要在小程序管理后台配置“被跳转”允许列表双方都需要加白名单。跳转时不能携带敏感数据extraData数据量不要太大只放必要参数。被跳转的小程序不能主动“反向跳回”原小程序除非原小程序也在对方的合法跳转列表里。实际项目里要设计一个“返回原小程序”的按钮就得再调一次navigateToMiniProgram指向原小程序而不是依赖系统返回。跳转过程中如果用户没有安装微信目标版本或没有打开目标小程序权限会走到fail回调。还有一点很容易踩坑不能通过navigateToMiniProgram跳转到同一个小程序自己。我们早期测试的时候想模拟“用户从小程序A跳到A”结果直接失败文档里没有明说查了社区才知道这是不合法的场景。3.3 通过场景值区分小程序进入来源当目标小程序收到跳转时它的onLaunch或onLoad会带一个scene参数。navigateToMiniProgram跳过来的场景值是1037或1038从另一个小程序返回或进入。通过场景值可以判断用户是自然打开还是从合作方导流过来从而决定是否执行后续的联合登录、埋点上报等逻辑。App({ onLaunch(options) { const { scene, query } options; if (scene 1037 || scene 1038) { // 从其他小程序跳转而来处理导流参数 console.log(导流参数, query); } } });这个场景值判断在联合运营里非常有用。我们当时的做法是从B小程序跳回A时B在extraData里带回业务凭证A拿到凭证后调后端接口完成两边的数据打通。整个过程用户感知就是“点了一下又回到原来的地方状态还保留了”体验比较好。4. 小程序与外部世界互跳URL Scheme、URL Link与H5开放标签如果说小程序内部的跳转是基础能力跨小程序跳转是合作能力那小程序和外部世界的互跳就是商业化能力的核心了。短信营销、邮件营销、广告投放、App导流全都要靠这一层打通。4.1 URL Scheme和URL Link的分工微信生态里有两个容易混淆的跳转方案——URL Scheme和URL Link。最早开发的时候我也搞混过以为它们是一回事后来发现完全不同。URL Scheme形如weixin://dl/business/?txxx的链接适合 App 内部或者短信、邮件等非微信环境唤起小程序。但URL Scheme有一个致命的限制在微信内置浏览器中被屏蔽。URL Link形如https://wxaurl.cn/xxx的链接可以理解为URL Scheme的升级版。它可以在微信内被直接打开并跳转到小程序也能在外部浏览器中唤起小程序。而且URL Link可以携带更多参数有效期也可以配置。实际选型逻辑我总结成一句话如果跳转目的地是微信环境优先用URL Link如果是短信、邮件、自有App等微信外场景URL Scheme或URL Link都能用但要注意各平台的兼容性。生成URL Scheme和URL Link都要求小程序是已发布的正式版并且需要在后台开通“获取URL Scheme”和“获取URL Link”的权限。生成接口一般放在后端因为需要调用access_token。一个简化版的后端生成示例Node.jsconst axios require(axios); async function generateUrlLink(accessToken, path, query) { const url https://api.weixin.qq.com/wxa/generate_urllink?access_token${accessToken}; const payload { path: path, query: query, is_expire: true, expire_type: 1, expire_interval: 30 }; const response await axios.post(url, payload); return response.data.url_link; }这里要特别注意expire_interval短链接有效期默认30天最长的有效期类型不同取值也不同。如果是做长期投放要注意链接过期问题定期重新生成或者干脆把过期时间拉满。4.2 H5页面直接拉起小程序开放标签如果你是一个H5页面的运营方希望用户点击一个按钮直接进入同主体或关联的小程序页面可以用微信内置的开放标签wx-open-launch-weapp。这东西在微信内置浏览器里支撑起了大部分“H5 - 小程序”的跳转。使用前提不少你的H5页面必须绑定在某个公众号下而且这个公众号需要与目标小程序有绑定关系页面域名必须在小程序后台配置为业务域名。开放标签的使用方式是把它当作一个DOM元素插入页面并在里面放一个触发按钮的模板wx-open-launch-weapp idlaunch-btn usernamegh_xxxxx pathpages/index/index?id100 script typetext/wxtag-template style.btn { color: #fff; background: #1aad19; padding: 12px 24px; }/style button classbtn打开小程序/button /script /wx-open-launch-weapp然后通过JS API监听点击后的跳转状态const btn document.getElementById(launch-btn); btn.addEventListener(launch, (e) { console.log(跳转小程序成功); }); btn.addEventListener(error, (e) { console.log(跳转失败, e.detail); });这个方案的坑主要在样式上开放标签内部的模板是隔离的写不了太多复杂的样式和逻辑。最稳妥的做法是标签内放一个简单按钮复杂交互放在标签外部点击外部区域时通过launch方法触发跳转。4.3 原生App跳转小程序匹配AppID与SDK接入原生App跳小程序属于另一套体系。以常见的移动App为例你需要首先在开放平台将App与小程序关联然后App端接入对应的SDK。核心逻辑App拿到用户的登录凭证后调用SDK里的WXOpenMiniProgram类型的API传入目标小程序的原始ID和页面路径微信客户端负责完成拉起。代码示意Android端抽象写法不同平台API各有差异// 需要引入开放平台SDK之后调用 WXOpenMiniProgramReq req new WXOpenMiniProgramReq(); req.userName gh_xxxxx; // 目标小程序的原始ID req.path /pages/detail/detail?id88; req.miniprogramType WXLaunchMiniProgramReq.MINIPROGRAM_TYPE_RELEASE; api.sendReq(req);这套方案里最容易出问题的点是App和小程序的绑定关系没配好、userName填的是AppID而不是原始ID、miniprogramType枚举值没对齐。其中原始ID这个东西很多人第一次接触会搞混。AppID是wx开头的字符串原始ID是gh_开头的字符串跳转用的绝大多数是原始ID。我早期就踩过一次拿着AppID填到userName字段里Android上跳转失败iOS上直接没反应。排查了半天才发现是字段用错。后来我养成一个习惯所有跳转相关的小程序标识都统一在后端配置常量字段注释写明“这是原始ID”防止前后端信息不同步。5. 参数传递、场景值与回调跳转后的数据怎么跟得上跳转从来不只是“页面动了”数据能不能跟着过去回来的时候状态还在不在才是衡量体验好不好的关键。这一节重点讲我处理过的几个数据衔接问题。5.1 跳转参数的安全传递与编码在前文已经提过encodeURIComponent这里展开讲讲。小程序跳转的参数传递有几个层次url路径后拼接的query参数适合基础字符串参数。extraData对象参数适合结构化数据但也要注意体积和序列化。全局变量或本地缓存适合跳转前后多次访问的数据。我处理订单确认页跳转支付时的习惯做法是订单ID放query本次支付的会话密钥放extraData而完整的订单详情数据存一份在本地缓存里。这样做的好处是如果支付过程被杀进程用户重新进入小程序还能从缓存恢复之前的订单草稿。参数编码这件事值得再强调凡是经过URL传输的字符串统一先编码再拼接。编码和解码要成对出现。接收端解码之后再做一次非空和长度校验防止别人恶意构造参数。5.2 场景值scene在跳转场景里的实际用法场景值是小程序判断流量来源的秘密武器。不同入口进入小程序scene值不同这决定了你该展示什么内容、执行什么逻辑。跳转相关的常见场景值我整理了一个表格场景值含义1007单人聊天会话中的小程序消息卡片1008群聊会话中的小程序消息卡片1011扫二维码打开1012长按图片识别二维码打开1037小程序打开小程序从另一个小程序进入本小程序1038从另一个小程序返回本小程序1047朋友圈广告打开1089微信聊天主界面下拉打开实际项目中用户从小程序A跳小程序BB页面要展示“来自A的用户专享礼包”就需要在onLaunch阶段解析scene和query把来源信息存到全局页面渲染时读取。我建议尽早做场景值映射表因为微信会时不时增加新的场景值每次发版前都值得去官方文档刷新一遍认知。5.3 跳转后的回调与状态同步navigateToMiniProgram跳走之后等用户再回到原小程序原小程序并不会主动刷新页面。这里有三类状态需要手动同步页面数据用户可能在目标小程序里修改了个人信息、完成了订单支付。登录态目标小程序里可能已经切换了账号回到原小程序不能继续用旧的登录态。业务状态比如目标小程序里领取了优惠券原小程序需要及时更新角标。我的解法比较朴素原小程序在小程序切后台再切回前台时在App.onShow里做一次基础状态同步同时和目标小程序约定好如果涉及关键业务变更目标小程序在返回前通过extraData回传一个标志位。原小程序在App.onShow读取到标志位后再决定要不要重新拉取完整数据。App({ onShow(options) { if (options.referrerInfo options.referrerInfo.extraData) { const { needRefresh } options.referrerInfo.extraData; if (needRefresh) { // 触发全局数据刷新 this.globalData.needRefresh true; } } } });这个方案能解决大部分状态不同步问题但要注意extraData回传的内容必须有预期约定不能放业务无关数据。6. 实际踩坑记录跳转失败的排查链路无论文档写得多清楚线上出问题的时候还是很折腾。这里把我实际遇到过的几次跳转失败案例拆开来讲希望能帮大家建立一条可复用的排查链路。6.1 从H5打开小程序按钮没有反应现象H5页面里嵌了wx-open-launch-weapp在微信里打开点击按钮没有反应控制台也没有明显的错误输出。排查过程我按这几步走先确认当前浏览器是微信内置浏览器外部浏览器里开放标签不生效不是bug是设计限制。再确认公众号和主域名的绑定关系H5页面所在的域名必须在小程序后台“业务域名”里配置过且校验文件已正确上传。看username是否是目标小程序的原始ID。很多人这里填了AppID怎么点都没反应。用微信开发者工具里的“公众号网页测试”工具检查签名和配置。最后发现我们的问题出在第二步业务域名校验文件虽然上传了但是上传的是旧版文件内容改版后校验文件内容变了后台没有同步更新。重新生成校验文件放回服务器刷新页面后立即恢复正常。6.2 navigateToMiniProgram跳转成功但目标页面空白现象A小程序调navigateToMiniProgram跳转动作本身成功了目标小程序能打开但页面是白屏。从目标小程序自己的后台日志看访问量有增加说明不是没进去而是里面报错了。进一步排查目标页面路径传的是pages/index/index但目标小程序里这个页面根本没有被任何入口引用也没有注册在app.json的pages列表里。跳转API并不会帮你校验目标页面是否存在它只管把用户带过去到了之后找不到页面就白屏。解法很简单跳转前先和目标小程序确认页面路径合法并且目标小程序要确保这个页面在版本里真实存在。为了减小这类问题影响我们后来在A小程序的配置后台维护了一份“允许跳转页面白名单”运营配置跳转参数时只能从白名单里选目标页面杜绝手动输入路径导致的低级错误。6.3 URL Link在Android/iOS上表现不一致现象同一个URL LinkiOS上正常打开小程序Android上却跳到下载页或者提示链接无效。URL Link这个方案虽然设计上比URL Scheme通用但真机上的兼容性仍然会有差异。最常见的原因是Android端微信版本过低不支持URL Link特性。遇到这种情况只能提示用户升级微信没有别的办法。另一个原因是URL Link的有效期问题。如果后端生成了短时效链接运营配置落地页时用了过期链接用户点开自然失败。我们后来在后端加了一个检测接口运营配置链接的时候自动请求一次验证链接是否还在有效期内过期就直接拦截报错。6.4 跳转参数中的特殊字符导致目标页取不到值现象URL参数里带了一个电商优惠券编码里面含有和/字符目标页面解析后变成了空格和乱码。根因就是参数没有正确编码。在URL解码时会被当作空格。常规做法是前端拼URL时做encodeURIComponent后端生成URL Link时也要在服务端同样编码一次不能只依赖客户端。我在做后端生成链接的逻辑时都会额外加一层编码日志把编码前后的参数打印出来对比。这样一线排查的时候能快速判断是生成环节的问题还是解析环节的问题。7. 跳转API的稳定性与降级策略跳转类功能最怕线上突然不可用。虽然微信提供的这一类API整体稳定性不错但任何依赖外部平台的跳转都会受到版本、网络、策略调整的影响。我这里分享几个稳定性层面的经验。7.1 控制跳转频率与失败重试不要在一个页面里连续多次调用跳转API。用户在短时间内点了好几次按钮前端要做防抖或者节流。navigateToMiniProgram的连续调用可能出现“跳转成功一次后二次调用无响应”的现象大概率是上一次跳转流程没有完全结束。失败后的重试也要带重试次数上限并且两次重试之间至少间隔数秒。有一次线上活动用户疯狂点击导致按钮触发多次失败重试日志里一瞬间打了几十个错误请求后端短暂出现告警。后来我统一封装了一个跳转工具类所有跳转按钮统一走这个类内置防抖、防重复调用、失败重试上限。7.2 做好跳转失败的兜底反馈很多开发者在fail回调里什么都不做或者只是打个日志。用户侧的表现就是“点了一下没反应”极其伤体验。我建议在fail回调里至少做一件事弹一个Toast提示说明当前跳转失败并提供备选操作比如复制跳转链接让用户自己到浏览器打开。wx.navigateToMiniProgram({ appId: 目标AppID, path: pages/index/index, fail(err) { wx.showToast({ title: 暂时无法跳转请稍后重试, icon: none }); // 同时把降级链接写入剪贴板 wx.setClipboardData({ data: https://fallback.example.com }); } });有人可能会问跳转失败是小概率事件值得为它写这么多逻辑吗我的看法是恰恰因为是小概率用户遇到时的困惑感更强。一个清晰友好的兜底反馈能挽回很多流失。7.3 线上线下环境隔离配置跳转API的对环境要求很敏感。开发版小程序跳转体验版小程序需要特定权限体验版跳转正式版的情况也分多种。为了不让环境问题干扰日常调试我在项目里维护了一套环境变量配置按开发、测试、预发、生产四个环境分别管理跳转目标AppID、URL Scheme、URL Link的后端域名。这套配置的好处是线上出问题时可以快速判断是不是因为后台配置被误改成测试环境导致。有一次夜班排查问题花了一个多小时才发现运营在后台把正式投放的URL Link配置成了测试链接而测试链接对应的页面路径根本不存在。有了环境隔离配置之后这类问题能在十分钟内定位。8. 跳转参数的组合应用一套完整落地案例为了方便理解我在这里把跳转API怎么组合使用做个完整演示。设想一个模拟项目——“某跨平台导购小程序”需求如下用户从外部App的短信营销链接进入小程序商品详情页用户在详情页看到另一个合作商城的优惠信息点击跳转至合作商城小程序领券领券完成后用户返回原小程序原小程序刷新优惠券角标。8.1 后端生成URL Link并拼接落地参数首先在后端生成带参数的URL Link// 简化示例生成URL Link const accessToken await getAccessToken(); const response await axios.post( https://api.weixin.qq.com/wxa/generate_urllink?access_token accessToken, { path: pages/goods/detail, query: goodsId encodeURIComponent(goodsId) channelsms } ); const urlLink response.data.url_link; // 拼接进短信内容注意这里query里的channelsms是给后续做渠道分析用的。用户从短信点进链接后小程序端会拿到这个参数。8.2 小程序商品页判断来源并触发跨小程序跳转商品详情页onLoad时解析参数Page({ onLoad(options) { const { goodsId, channel } options; // 记录渠道来源 reportChannel(channel); // 加载商品数据 this.loadGoods(goodsId); } });用户点击“领券”按钮时调用跨小程序跳转handleGoCoupon() { wx.navigateToMiniProgram({ appId: 合作小程序的AppID, path: pages/coupon-center/coupon-center?fromguide, extraData: { token: this.data.userToken }, success() { // 跳转成功记录埋点 }, fail(err) { // 提示用户复制链接去App参与活动 wx.setClipboardData({ data: https://fallback.example.com/coupon }); wx.showToast({ title: 跳转失败已复制备用链接, icon: none }); } }); }8.3 合作小程序领券后回传状态合作小程序的领券中心页面在用户完成领券操作后调用wx.navigateBack回到原小程序前或者在返回按钮逻辑里通过extraData回传状态。但要注意navigateToMiniProgram的返回并不支持直接向原小程序传数据原小程序只能在App.onShow里读取options.referrerInfo.extraData。于是合作方小程序的对应逻辑写成这样// 合作小程序领券成功跳回原小程序 handleBack() { wx.navigateToMiniProgram({ appId: 原小程序的AppID, path: pages/goods/detail?goodsId this.data.goodsId, extraData: { couponStatus: SUCCESS } }); }8.4 原小程序收到回传后刷新状态原小程序的App.onShow接收回传状态App({ onShow(options) { const extraData options.referrerInfo options.referrerInfo.extraData; if (extraData extraData.couponStatus SUCCESS) { // 通知当前页面刷新优惠券状态 const pages getCurrentPages(); const currentPage pages[pages.length - 1]; if (currentPage typeof currentPage.refreshCoupon function) { currentPage.refreshCoupon(); } } } });到这里整个“外部链接进入 - 跨小程序领券 - 返回原小程序刷新状态”的链路就完整闭环了。如果在真实项目里要继续扩展到微信群分享卡片进入、朋友圈广告进入只需要在最前面的入口层各加一个页面路径解析后面的链路完全复用。9. 个人经验与最后的几个提醒跳转API本身不复杂真正复杂的是对业务场景的理解和对平台规则的敬畏。我自己做了这么多年最大的感受是每次以为自己完全掌握了跳转能力总会在某个边缘场景上发现新的限制或坑。说几个我个人的习惯也许对你有参考价值。第一我会把所有跳转相关API统一封装成一个跳转管理中心业务侧不要直接调官方API。统一封装的好处是拦截异常、统计跳转成功率、统一处理降级逻辑、控制环境变量切换这些事分散到业务代码里几乎没人能坚持做完整。第二每次小程序版本发布之前花半小时把所有跳转入口完整走一遍。手动过一遍iOS和Android真机上的跳转路径哪怕只是核心链路。不要觉得麻烦跳转功能一旦失效用户反馈速度远超你的想象与其线上被用户骂不如发布前自己多跑两遍。第三警惕新版本API替代旧API的节奏。微信不断在更新跳转能力比如旧版分享到朋友圈的能力在收紧替代方案陆续出现。不要在技术栈上固步自封每半年花点时间对照官方更新日志确认自己用的方案仍然处于健康状态这一点在长线运营的项目里非常重要。跳转API写起来简单跑通容易但做到稳定、可监控、可降级需要投入的精力远比想象得多。如果这篇文章能让你在动手之前少踩几个坑我觉得这个篇幅就值了。
