تسجيل الدخول الآن 抽奖小程序看起来并不复杂：用户点一下按钮，等一个结果，顺手分享出去，流程好像也没什么。但真正落地时，页面之间怎么连起来，往往比抽奖动画本身更影响体验。活动说明、抽奖规则、奖品领取方式，还有活动结束后该展示什么页面，都需要有合适的跳转入口。这里最容易碰到的问题是：小程序里怎么把一段文字或一个按钮变成“超链接”，让用户点到之后自动去指定页面？
早期资料里，常见类似网页的写法，例如在文字上挂一个 href，点击后跳转。放到小程序里，更贴近原生的做法通常是使用可跳转组件，并通过 url 属性指定目标页面。比如活动页上有一个“查看抽奖规则”的入口，可以这样写：
<navigator url="/pages/rules/rules">查看抽奖规则</navigator>
这里的 /pages/rules/rules，表示要跳过去的页面路径。用户点击“查看抽奖规则”后，小程序会跳转到规则页。对这类展示型入口来说，这种方式比较直接，页面上也能一眼看出哪些文字是可点击的，后续维护时不容易混乱。
不过，实际项目里并不是所有跳转都适合直接写在模板里。有时候，点击之后需要先判断状态：用户是否登录，活动是否已经结束，是否已经中过奖，跳转前是否要携带参数。这类场景如果全写死在组件里，逻辑会很僵。更灵活的方式，是在点击事件里调用小程序提供的页面跳转 API。
还是以跳转规则页为例，可以在 Page 中写一个处理函数，再把这个函数绑定到按钮或文字上：
Page({
goToRulesPage() {
wx.navigateTo({
url: '/pages/rules/rules'
});
}
});
当用户点击对应元素时，就会触发这个函数，再由函数执行跳转。相比直接在模板里写跳转，这种方式的好处是可以加入更多判断。比如“我的奖品”这个入口，用户没中奖时可能需要弹提示，已经中奖时则跳领取页；活动未开始时跳预告页，活动结束后再跳结果页。这种带条件分支的交互，用事件函数处理会自然很多。
跳转 API 也不是只有一种，不同场景下差别挺大。wx.navigateTo 会打开一个新页面，当前页面仍然保留在页面栈中，用户点返回还能回到原来的抽奖页。这种用法适合规则页、活动说明、奖品详情这类“看一圈再回来”的页面。wx.redirectTo 则会关闭当前页，再打开目标页，用户没办法通过返回按钮退回到被关闭的那个页面。它更适合流程已经走完、没有必要再回头的场景，比如活动结束后统一跳到落地页。wx.navigateBack 则是返回上一页，常用于弹窗里的“返回活动”“继续抽奖”这类操作。
这里有一个容易被忽略的点：小程序里的页面路径并不是随便写的。目标页面通常需要在 app.json 中注册，路径也要和项目结构保持一致。如果路径写错，或者页面没有配置，跳转很可能会失败。实际开发中，这类问题不一定表现为特别明显的报错，有时只是点击后没反应，或者跳到空白页，所以联调时最好顺手把路径、页面注册、参数传递一起检查一遍。
还有一点和体验关系很大：抽奖小程序里的跳转，最好别做得太绕。用户参与抽奖时，注意力通常很短，如果点一个“规则”还要经过好几层页面，耐心很容易消耗掉。比较合理的做法是，关键入口放在显眼位置，比如按钮下方、奖品区域旁，或者活动说明里；跳转层级尽量浅，规则页和领奖页能快速打开，也能快速返回。如果活动里还需要打开外部 H5 页面、公众号文章或第三方页面，那就不能只靠小程序内部路径解决，通常要结合 web-view 等能力处理，同时还要留意合规和加载体验。
说到底，抽奖小程序里的“超链接”跳转，表面上看只是“点一下去另一个页面”，真正做的时候，却会牵涉到模板写法、事件逻辑、页面栈管理，甚至活动流程设计。把这两类方式用起来并不复杂：简单入口可以直接用组件承载，复杂逻辑交给事件函数和 API 处理。只要路径正确、跳转层级清晰，用户在整个抽奖流程里的体验就会顺滑很多。