지금 로그인 说起小程序，这几年确实改变了不少人的使用习惯，不用下载安装，打开就能用，用完即走。不过对开发者来说，页面跳转这件事远不止点一下按钮换个界面那么简单。它背后涉及页面栈、数据传递和用户体验的连贯性，稍不注意就会出现白屏、跳转混乱或者数据丢失。所以，把小程序跳转的基本逻辑理清楚，对做出流畅的应用会很有帮助。
小程序里每个页面都有一个唯一的路径标识，就像网页的 URL，可能是“pages/index/index”这种纯路径，也可能带上参数，比如“pages/detail/detail?id=123”。从一个页面去另一个页面，本质上就是调用系统提供的 API，告诉它“我要去那个路径，并且带上这些数据”。触发跳转的动作也很丰富，除了最常见的点击按钮，滑动某个区域、长按图片、扫码识别，甚至从后台消息模板点进来，都能成为跳转的入口。
很多开发者一开始只知道用 <navigator> 组件，直接在 wxml 里写好目标页面和参数，简单直接。这种声明式跳转确实最常用，比如从列表页进入详情页，把商品 ID 传过去，逻辑很清晰。但有些场景 <navigator> 覆盖不了，就需要调用不同的 API。
比如 wx.redirectTo，它和普通跳转最大的区别在于会关闭当前页面再打开新页面。这通常用在登录成功后，你肯定不希望用户点了返回还能回到登录页，所以用 redirectTo 把登录页从页面栈里踢掉就很合理。wx.navigateBack 则是用来返回上一页的。还有一种场景是底部 tab 栏的切换，必须用 wx.switchTab，因为 tab 页的跳转不能走普通的页面栈，否则会把 tab 栏的选中状态搞乱。这些方法各有各的适用场景，选错了，轻则返回按钮逻辑不对，重则整个应用流程断裂。
在实现技巧上，我踩过不少坑，有几个点特别值得留意。
首先是数据传递。最简单的方式就是拼在 URL 参数里，比如 ?id=1&name=test，但这种方式只能传字符串，如果数据量大或者有复杂对象就不太方便。实战中，我经常用全局变量或者缓存来做中转，例如下单流程里，先把用户选择的地址、优惠券信息存到 getApp().globalData 里，跳转到确认订单页再取出来。虽然多写几行代码，但数据完整性更有保障。当然，也可以用事件通道或者页面栈中前一个页面实例来传递，只是那种方式耦合度稍高，需要根据实际情况权衡。
其次是页面注册。很多新手会发现，明明路径写对了，跳转就是报错，一查才想起来忘了在 app.json 的 pages 数组里注册。小程序所有的页面路径都必须提前声明，包括分包里的页面，漏掉一个就会直接报“页面不存在”。这个规则虽然基础，但在频繁加页面的时候确实容易被忽略。
还有一个很关键但容易被忽视的地方，就是页面栈的管理。小程序的页面栈最多只能存 10 个页面，超过限制之后，最底部的页面会被自动销毁。如果你在做流程比较长的表单填写，或者从首页一直点进第五层、第六层分类，很可能不知不觉就堆满了。这时候再用 wx.navigateTo 就会失败，页面毫无反应。所以，对于层级较深的场景，要有意识地用 redirectTo 替换掉一些不必要的中间页，或者尽早用 navigateBack 返回，避免栈溢出。另外，页面跳转过程中如果用户快速点击，也可能触发多次跳转，导致页面栈混乱，通常需要在点击事件里做一下防抖处理。
回过头来看，小程序的跳转功能虽然看起来只是几个 API 的调用，但真正用好，需要结合业务场景去设计页面流转逻辑，处理好数据传递和异常情况。比如电商里，从商品列表到详情，再到下单、支付，每一环的跳转和返回，都直接影响用户的购买体验。如果能在这些细节上多下功夫，应用的整体流畅度就能上一个台阶。希望这些梳理，能让你在开发时少走一些弯路，也更清楚每种跳转方式背后的设计意图。
