一、背景
离上次写文章过了快一年了，这一年里经历了很多，成长了很多，也颓废了很多。到了现在的这个时间点，需要重新拾起以前记录的习惯，积累着自己的获得，沉淀着自己的底蕴。这段时间，我做的业务主要在于微信小程序，难免会遇到各种情况下跳转小程序的业务场景，在沉淀了一段时间后，特此做一个总结，希望能够给遇到类似需求的前端开发一点帮助。
二、跳转小程序的业务场景
说一千道一万，前端所在的运行环境就那么几种，初见觉得复杂，习惯了之后也觉得就那样，熟能生巧。基于此，我将跳转小程序的业务场景分为下面4种情况：
- App webview 环境中，通过 bridge 让App原生完成跳转小程序逻辑。
- 小程序 webview 环境中，如果是跳转当前小程序，那么通过 wx.naviagteTo() 跳转。
- 小程序 webview 环境中，如果是跳转第三方小程序，那么通过当前小程序原生中间页用户主动点击触发 wx.navigateToMiniProgram() 跳转。
- 浏览器环境中（包括微信浏览器和普通浏览器），通过后端借口生成微信小程序 urllink 的方式完成跳转小程序的逻辑。
三、具体说明
第二部分所说的场景基本已经涵盖了我们日常的使用业务了，其中对于3、4点需要进行具体说明。第3点指的是小程序A的 webview 里面打开的 h5 页面需要点击某个按钮跳转到小程序B中。看起来有点绕，但是在做一些对外合作的业务中其实是经常遇到的。这种情况下，微信官方是做了限制的。它不允许直接在h5进行跳转，而是需要在小程序A的原生液吗做一次中转，并且这次中转页中必须是用户手动点击才能触发跳转到小程序B中。所用的api也就是 wx.navigateToMiniProgram()。目前来说，无法绕过这个限制。
对于第4点的浏览器环境中跳转小程序，这个应用范围很广，例如给用户发营销短信带一个小程序链接🔗。这种方式的底层是运用了小程序官方提供的短链机制。这个短链目前已经被大部分浏览器支持了，目前来说没有碰见不支持的。其大致生成逻辑是，前端调用后端接口，后端调用微信接口生成相应短链。
其中需要注意两点：
- 后端调用微信接口是需要带一个凭证的，避免凭证失效，接口调用失败。
- 经过微信改版后，生成的短链是一次性的，无法多次使用。所以对于此种方案，需要做一些逻辑每次用户点击都生成一个新的短链，不然真的要坑死人了！
四、总结
上面总结了一些场景中跳转小程序的方案，但是随着微信小程序的更新，难免会出现更加优雅的处理方式。希望看到本文的开发者能够积极思考，找到更贴合自己业务场景的方案，over！
