立即登录 小程序这几年能快速铺开，很大程度靠的是“用完即走”的轻便体验。但这个“轻便”有个前提：页面之间得衔接顺畅。跳转一旦做得不好，用户很快就会遇到卡住、点不动、回不去的情况。别看跳转在代码里常常只是几行调用，它其实贯穿了用户在小程序里的每一次操作——从商品列表点进详情、扫码打开活动页、支付完成跳回订单列表，背后都靠它撑着。
从实现原理上说，跳转并没有太多神秘的地方。每个页面都有唯一标识，一般是路径，有时还要在路径后面带参数。开发者调用小程序提供的 API，就能让当前页面切到目标页面。触发跳转的方式也不止点击按钮，滑动、扫码、支付回调、某些条件下自动弹转，都能成为入口。跳转因此不只是一个组件的事，它更像一条线，把不同页面按业务逻辑串起来。
实际开发里，最常用的还是 navigator 组件。它就像页面里的一个链接，写在结构里，把 url 和参数设置好，用户一点就能跳。但有些场景不适合用 navigator，比如登录成功后不想让用户再返回登录页，这时用 redirectTo 直接替换当前页会更干净。navigateBack 用于返回上一页，使用简单，但要注意返回后页面栈的变化。还有 switchTab，专门用来切换底部 tab 页，和普通页面跳转的规则不一样，混着用很容易跳转失败或层级错乱。所以选哪种跳转方式，首先要看页面在业务里是什么角色：是普通页、tab 页，还是要替换当前页。
跳转本身不难，真正容易出问题的是几个细节。最容易先碰到的是数据传递。从列表页跳到详情页，新页面得知道用户点的是哪条数据。常见做法是把参数拼在 URL 后面，这种方式最直接，但数据量大了会有长度限制和编码问题。全局变量和缓存更适合放临时状态或体积较大的数据，不过要记得及时清理，否则容易残留脏数据。页面路径也常常出问题。所有要跳转的页面路径都必须提前在 app.json 里注册，路径写错或没注册，跳转就直接失败。再往后是页面栈管理。小程序对页面栈的层数有限制，用户连续点很多层后，再继续跳就可能报错。所以像 redirectTo、navigateBack 这些操作要提前设计好，避免用户一路点下去，最后卡在某个页面回不去。
从用户角度说，跳转做得顺，往往是“无感”的：点了就有响应，返回时状态还在，不会莫名其妙多出一层同样的页面。但一旦出问题，体感会非常明显。合理使用跳转方式，配合清晰的数据传递和页面栈控制，能明显提升小程序的完成度。跳转功能不算复杂，但它很考验开发者对业务路径的理解。把基础方法摸熟，再结合具体场景多试几遍，大部分跳转问题都能提前避开。
