做微信小程序，卡在路由跳转这一步。不是报错就是页面空白，或者跳转后数据丢了。今天我直接拿我手头一个本地生活服务类的小程序当例子，把路由方法拆开揉碎了讲清楚。这套东西你要是吃透了，不光技术问题能解决，连怎么用路由设计去引导用户成交，你都能摸出门道。

先搞清楚微信小程序里路由到底是个啥。简单说，就是页面之间的切换逻辑。你点一个按钮，从首页跳到商品详情页，这叫路由跳转。你提交订单后自动跳到支付页，这也是路由。但很多开发者在做这一步的时候，只想着“能跳就行”，根本没考虑用户在这个跳转过程中的心理状态和成交可能性。

微信小程序提供了五种路由方式：navigateTo、redirectTo、switchTab、reLaunch、navigateBack。我一个个说，每个我都会结合成交场景来讲，不是光念API文档。

第一个，navigateTo。 这个最常用，保留当前页面，跳转到应用内的某个页面。比如用户在你首页看到一个“限时秒杀”的banner，点击后跳到秒杀商品列表页。这时候用户还能通过左上角返回按钮回到首页。这个设计的好处是什么？用户浏览路径是连续的，他可以在首页和秒杀页之间来回切换，对比商品。我见过很多失败的案例，就是这里用了redirectTo，用户一点秒杀banner，首页没了，想回去看别的商品还得重新扫码进小程序，成交率直接砍半。所以记住：当用户可能还需要回到上一级页面做决策时，必须用navigateTo。 具体操作：在wxml里绑定bindtap事件，js里写wx.navigateTo({ url: '/pages/seckill/seckill' })。注意url前面要加斜杠，路径要写全。

第二个，redirectTo。 关闭当前页面，跳转到新页面。这个适合什么场景？用户填写完订单信息，点击“去支付”，这时候订单页已经没用了，用户不需要再回来修改（除非你设计了修改入口，但一般支付流程是单向的）。用redirectTo跳转到支付页，能避免用户误操作返回订单页重复提交。我做过一个本地餐饮小程序，用户点餐后从菜单页跳转到结算页，我用的是navigateTo，结果用户返回菜单页又加了一份菜，导致订单金额对不上。后来改成redirectTo，这个问题就没了。操作上，wx.redirectTo({ url: '/pages/payment/payment' })，用法和navigateTo一样，区别就是当前页面会被销毁。

第三个，switchTab。 跳转到tabBar页面，并且关闭所有非tabBar页面。这个最容易出问题。以为tabBar页面就是底部那几个导航栏页面，随便跳。但switchTab有个坑：它不能传递参数。比如用户从商品详情页点击“购物车”tab，你想把商品ID带过去，用switchTab是做不到的。怎么办？我自己的做法是用全局变量或者本地缓存。在商品详情页把数据存到app.globalData或者wx.setStorageSync里，然后在购物车页的onShow生命周期里读取。虽然麻烦点，但这是唯一可靠的办法。还有一种骚操作：用navigateTo跳转到购物车页，但这样底部tab会被覆盖，用户体验不好。所以switchTab只适合纯粹的页面切换，不需要传参的场景，比如从任何页面跳回首页。

第四个，reLaunch。 关闭所有页面，打开到应用内的某个页面。这个威力最大，也最容易被滥用。什么时候用？用户登录态失效了，你从任何页面直接跳转到登录页，并且清空所有页面栈，防止用户通过返回按钮绕开登录。另一个场景：用户完成支付后，你想让他直接回到首页重新浏览，而不是留在支付成功页。用reLaunch('/pages/index/index')，干净利落。但注意，reLaunch会触发页面的onUnload和onLoad，如果你的页面有大量初始化请求，频繁reLaunch会导致性能问题。我一般只在关键的流程节点用，比如支付完成、退出登录、强制升级。

第五个，navigateBack。 返回上一页或多级页面。这个看似简单，但不知道怎么传参。比如用户从商品列表页进入详情页，在详情页操作后返回列表页，你想刷新列表数据。直接在navigateBack里没法传参，你得用getCurrentPages()拿到上一页的实例，然后直接修改上一页的data。具体代码：const pages = getCurrentPages(); const prevPage = pages[pages.length - 2]; prevPage.setData({ refresh: true }); 然后上一页在onShow里检测这个refresh变量，决定是否重新拉取数据。这个技巧在电商类小程序里非常实用，用户从详情页加购后返回列表页，列表页自动更新库存显示，成交转化率能提升不少。

讲完五种方法，我再说一个忽略的核心问题：页面栈深度。微信小程序默认页面栈最多十层。超过十层，navigateTo会直接失效，而且没有错误提示。我遇到过最离谱的案例，一个本地家政小程序，用户从首页->服务列表->服务详情->预约时间->填写地址->确认订单->支付->支付成功->评价，一路navigateTo下来，到第九层页面时，用户想返回首页，结果跳转失败，用户以为小程序卡死了，直接关掉走人。解决办法：在关键节点用redirectTo或者reLaunch清理页面栈。比如支付成功后，用reLaunch跳回首页，而不是继续navigateTo。或者用wx.navigateTo的events参数监听页面返回事件，在合适时机主动关闭中间页面。

说到成交，路由设计直接影响用户决策路径。我拿本地水果店小程序举个例子。用户进首页，看到“今日特价”banner，点击后应该用navigateTo跳到特价商品列表。用户选了一个商品，进入详情页，这里还是navigateTo。用户决定购买，点击“立即购买”，这时候用redirectTo跳到确认订单页，因为商品详情页已经完成了它的使命。用户提交订单，用redirectTo跳到支付页。支付成功，用reLaunch跳回首页，并显示一个“支付成功”的toast。整个过程，用户没有多余的返回按钮干扰，路径清晰，每一步都在引导他完成交易。反观很多小程序，所有跳转都用navigateTo，页面栈堆到十几层，用户想返回首页得点十几次返回，早就没耐心了。

还有一个细节：路由跳转时的loading状态。很多开发者跳转页面时啥也不管，用户点了按钮，页面白屏一两秒，用户以为没点到，又点了一下，结果跳转了两次。尤其是支付页面，重复跳转可能导致重复下单。解决办法：在跳转前加一个loading提示，用wx.showLoading，跳转成功后wx.hideLoading。或者用button的loading属性，点击后按钮变成禁用状态。我自己的习惯是在跳转方法里加一个防重复点击的锁：定义一个变量isJumping，默认为false，跳转时设为true，跳转完成或失败后再设回false。这个锁能避免99%的重复跳转问题。

最后说一个本地化相关的技巧。我做的小程序主要服务本地社区，用户经常需要从首页直接跳转到某个具体的商家页面。如果用navigateTo，用户返回首页时，首页会重新加载，之前浏览的位置丢失了。我用的方案是：首页用scroll-view记录滚动位置，跳转前用wx.setStorageSync保存scrollTop值，返回首页时在onShow里读取并恢复滚动位置。这样用户从商家页返回首页，还是在他之前看的位置，体验很顺滑。这个细节虽然小，但对本地生活类小程序的留存率影响很大，用户会觉得“这个小程序很懂我”。

总结一下我这几年的实战经验：路由方法不是技术选型，而是成交设计。navigateTo用于用户需要对比决策的场景，redirectTo用于单向流程，switchTab只用于无参数tab切换，reLaunch用于流程终点或状态重置，navigateBack配合getCurrentPages传参。页面栈深度控制在五层以内，超过就用redirect或reLaunch清理。每次跳转考虑用户下一步要做什么，而不是机械地写代码。你把这些想透了，你的小程序成交率至少能翻一倍。