在日常开发或使用小程序时，你可能遇到过这样的场景：用户正在浏览你的商城小程序，突然想看看关联的社区小程序里有没有相关讨论。这时如果能让两个小程序无缝跳转，体验会顺畅很多。但微信对小程序间的跳转有一套严格规则，第一次接触时容易踩坑。下面我会从原理到实操，把这件事彻底讲透。

一、跳转前的“硬门槛”：两个小程序必须绑定

先泼一盆冷水：不是任意两个小程序都能跳转。微信要求跳转双方必须属于同一个开放平台账号（即同一个主体，比如同一家公司或同一个开发者）。如果你打开小程序后台，进入“设置-关联设置”，会看到一个“关联小程序”功能。这里就是绑定入口。

具体操作：假设你的主小程序叫A，目标跳转小程序叫B。登录A的后台，点击“关联小程序”，输入B的AppID。此时B的管理员会收到一条关联申请，同意后，A和B就建立了“亲属关系”。注意，一个小程序最多可以关联500个其他小程序，但实际场景中关联几个核心业务就够了。

举个例子：某电商公司有“主商城小程序”和“售后助手小程序”，用户下单后想看物流，从商城跳转到售后助手。这两个小程序必须提前在后台绑定好，否则跳转时会直接报错“未关联”。

二、代码层的“跳转开关”：navigateToMiniProgram 的完整用法

绑定完成后，前端就可以用 wx.navigateToMiniProgram 这个API来触发跳转。但这里有个容易被忽略的细节：这个API必须由用户点击触发，不能自动调用（比如页面加载时直接跳转会被拦截）。

标准写法如下：

```javascript
wx.navigateToMiniProgram({
appId: '目标小程序的AppID',
path: '目标页面路径?参数名=参数值', // 可选，默认跳转到首页
extraData: {
key1: 'value1',
key2: 'value2'
},
envVersion: 'release', // 可选，跳转到开发版/体验版/正式版
success(res) {
// 跳转成功后的回调
},
fail(err) {
// 跳转失败后的回调，比如用户取消跳转
}
})
```

这里有个容易混淆的点：path和extraData的区别。path是在目标小程序打开时，直接让页面定位到某个具体页面（比如商品详情页）；而extraData是传给目标小程序的数据，目标小程序需要在App.js的onLaunch或onShow里通过options.referrerInfo.extraData来获取。举个例子，商城小程序跳转到社区小程序时，path可以设为“/pages/post-detail/post-detail?postId=123”，同时extraData里传一个用户token用于自动登录。

三、目标小程序如何“接住”跳转过来的数据

很多开发者只关心怎么跳出去，却忽略了目标小程序怎么接收数据。这里分两种情况：

情况一：通过path传递参数。比如跳转时path设为“/pages/detail/detail?id=100”，目标小程序的detail页面可以直接在onLoad里拿到options.id。这种方式适合简单的参数，但缺点是参数会暴露在URL里，且长度有限制。

情况二：通过extraData传递复杂对象。目标小程序要在全局的App.js里监听：

```javascript
App({
onLaunch(options) {
if (options.referrerInfo) {
const extraData = options.referrerInfo.extraData
// 这里可以存储到全局数据，或者通过页面通信传给特定页面
}
},
onShow(options) {
// 如果小程序从后台切回前台，也会触发onShow，同样可以拿到referrerInfo
}
})
```

注意：extraData里的数据只能通过App生命周期获取，不能直接在页面onLoad里拿到。所以通常的做法是：在App.js里把extraData存到全局变量，然后目标页面在onShow时去读取这个全局变量。我见过很多新手直接写在页面onLoad里，结果总是拿不到数据，就是因为忽略了数据传递的入口位置。

四、用户操作路径上的“隐形陷阱”

即便代码写对了，用户在实际操作时可能遇到三个让人抓狂的问题：

1. 用户取消授权弹窗：跳转时会弹出一个确认框“即将打开XX小程序”，如果用户点击“取消”，跳转就会失败。这个无法通过代码绕过，但你可以优化文案——在跳转按钮旁边加一句提示“点击后需确认跳转”，减少用户误操作。

2. iOS与Android的差异：在iOS上，跳转后目标小程序可能会直接覆盖当前小程序；在Android上，目标小程序会以半屏或全屏形式打开，用户可以通过左上角返回按钮回到原小程序。如果你的业务需要用户频繁在两个小程序间切换，建议在目标小程序里加一个“返回主小程序”的按钮，用同样的navigateToMiniProgram跳回来。

3. 跳转后原小程序状态丢失：如果原小程序被销毁（比如手机内存不足），用户从目标小程序返回时，原小程序会重新加载。解决方案是在原小程序的App.js里用onShow做状态恢复，比如重新请求用户登录信息。

五、一个完整的业务场景串联

假设你有一个“点餐小程序”和一个“评价小程序”。用户点完餐后，希望跳转到评价小程序写评论，并且自动带出订单号。

步骤1：在点餐小程序的“去评价”按钮上绑定点击事件：

```javascript
wx.navigateToMiniProgram({
appId: '评价小程序的AppID',
path: '/pages/write-review/write-review',
extraData: {
orderId: '20250315001',
userName: '张三'
}
})
```

步骤2：在评价小程序的App.js里接收：

```javascript
App({
globalData: {
orderInfo: null
},
onLaunch(options) {
if (options.referrerInfo) {
this.globalData.orderInfo = options.referrerInfo.extraData
}
},
onShow(options) {
if (options.referrerInfo) {
this.globalData.orderInfo = options.referrerInfo.extraData
}
}
})
```

步骤3：在评价页面的onShow里读取：

```javascript
const app = getApp()
Page({
onShow() {
const orderInfo = app.globalData.orderInfo
if (orderInfo) {
this.setData({
orderId: orderInfo.orderId,
userName: orderInfo.userName
})
}
}
})
```

这样用户跳转后，评价页面自动填充订单号和用户名，省去了手动输入的麻烦。

六、对比其他跳转方式：什么时候用navigateToMiniProgram，什么时候用web-view？

有些开发者会纠结：既然小程序里可以嵌入web-view，是不是通过web-view加载另一个小程序的H5页面也能达到类似效果？这里做个对比：

navigateToMiniProgram：原生跳转，用户能感知到“我离开了当前小程序”，适合需要明确切换场景的业务，比如从工具类小程序跳转到游戏类小程序。缺点是每次跳转都需要用户确认，流程稍长。

web-view加载H5：用户感觉还在当前小程序内，但实际上H5页面可以调用另一个小程序的云函数或接口。但这种方式无法直接使用另一个小程序的native能力（比如蓝牙、NFC），而且如果H5页面需要登录，可能涉及跨域问题。适合两个小程序共享同一套用户体系的情况。

还有一种更“野”的路子：通过小程序码跳转。生成一个包含目标小程序路径的小程序码，用户扫码进入。但这属于线下场景，和线上跳转是两套逻辑。

七、调试时的“救命”技巧

开发阶段，你可能会遇到跳转后白屏或者数据没传过去。这里分享三个调试方法：

1. 打开微信开发者工具的“真机调试”，在跳转前和跳转后分别打印日志。注意，跳转后原小程序的调试面板会断开，需要重新连接目标小程序的调试器。

2. 在目标小程序的onLaunch里加一个弹窗：

```javascript
wx.showModal({
title: '接收到的数据',
content: JSON.stringify(options.referrerInfo)
})
```

这样能快速确认数据是否到达。

3. 如果跳转时报错“appid not found”，99%的原因是没在后台绑定。重新检查关联设置，注意绑定后可能需要等待几分钟生效。

小程序跳转的本质是微信生态内的一种“页面路由”，它比网页跳转多了安全限制，但也提供了更可控的体验。当你把绑定、传参、接收、异常处理这一整套流程跑通后，你会发现两个小程序之间的协作可以像同一个应用内的页面跳转一样自然。关键在于理解微信的设计初衷：保护用户不被随意跳转打扰，同时给开发者留出合理的业务通道。