Se Connecter Maintenant 在小程序开发里，跳转到另一个小程序，往往不只是“打开一个新页面”这么简单。它常常连着一条完整业务链路：用户在商城小程序里看完商品，接着去支付小程序完成付款；在课程页了解完内容，再进入视频小程序继续学习；遇到售后问题，也能直接跳进客服小程序处理。功能拆得清楚，体验反而更顺，但前提是跳转链路要足够稳定。
先别急着写页面逻辑，配置这一步很关键。发起跳转的小程序通常要在 app.json 里声明目标小程序，常见字段是 requiredMiniprogramAppid，把目标小程序的 appid 填进去。这一步相当于提前告诉平台：当前小程序会调用其他小程序。如果漏配，后面页面入口写好了，跳转也可能不生效。实际项目里，不少跳转失败并不是页面逻辑写错，而是配置没有对齐。
页面层更常用的是 navigator 组件，因为它和按钮、卡片、横幅、列表项这些界面元素绑定得很自然。做跨小程序跳转时，open-type 一般设为 navigateToMiniProgram，再通过 app-id 指定目标小程序，用 path 指定目标页面，必要时还可以用 extra-data 传参数。比如商品详情页里的“去支付”按钮，点击后不是停留在当前小程序里继续流转，而是跳到支付小程序的收银台，同时把订单号、用户标识、来源渠道带过去。这样目标小程序打开后，就能知道这次支付从哪个场景来，后续展示和统计也更清楚。
参数传递容易被忽略，但很实用。两个小程序之间通常不是孤立运行的，跳转时需要留下上下文。电商小程序去支付，不能只打开一个空白收银台，至少要知道支付哪一笔订单；教育小程序去视频，最好告诉对方用户正在学哪门课、哪个章节；本地生活小程序去核销，也要带上券码或订单状态。extra-data 传的多是这类信息，通常是一个对象，可以包含订单号、会员 ID、活动 ID、来源页面等字段。
不过，目标小程序收到这些数据后，也不能想当然认为它们会直接出现在普通页面参数里。跨小程序跳转带来的额外信息，一般要在目标小程序的 onShow 或 onLaunch 生命周期里，通过 referrerInfo 读取，里面通常包含来源小程序的 appid 和 extraData。如果跳转路径里还带了 query，比如 pages/detail/detail?orderId=123，目标页面也可以在 onLoad 里读取路径参数。实际开发中，把 extraData 和路径参数分开处理会更清晰：一个负责业务上下文，一个负责页面定位。
除了 navigator，还有一种更灵活的写法：wx.navigateToMiniProgram。它更适合放在事件回调里，比如点击按钮、提交表单、登录成功之后，再根据条件决定是否跳转。调用时需要传入目标小程序的 appId，也可以选择传入 path 和 extraData；在测试阶段，还能指定环境版本，比如开发版、体验版或正式版。这个能力在联调时尤其有用，不用等上线，也能先验证跳转是否通。常见场景是：用户点击“继续观看”后，前端先判断是否登录，未登录就引导登录，登录成功后再调用 API 打开视频小程序。
跳转链路里还有一件容易被低估的事：兜底。理想情况下，用户一点就能进入目标小程序，但真实环境不一定每次都顺利。目标小程序可能不可用，appid 可能写错，网络可能异常，用户权限也可能不满足。如果这些情况都没处理，用户看到的可能只是“点了没反应”。更稳妥的做法，是准备备用页面或降级方案，比如跳到当前小程序内的说明页、H5 页面、客服入口，或者给出明确的失败提示。跳转不是终点，用户点下去之后有没有合理承接，才决定体验是否完整。
从实际场景看，小程序之间跳转的价值，不在于“能跳”，而在于跳得是否有意义。电商可以把商品浏览、支付、售后、评价拆到不同小程序，各司其职；教育可以把课程介绍、视频播放、作业批改、社区交流分开，让主流程更轻；工具类应用也可以把文档预览、在线编辑、翻译、导出等功能分散到不同入口。功能越复杂，越适合用跳转理清边界，而不是把所有内容都塞进一个页面。
所以，做小程序跳转并不是调用一个组件或一个 API 就结束。它背后是一条完整链路：先配置目标小程序，再设计页面入口，然后传递必要参数，同时处理好异常和兜底。做到这些之后，用户感知到的不是技术复杂度，而是顺畅感：该付款时有地方付款，该看视频时能继续看，该咨询时能快速找到入口。跳转做对了，功能边界会更清楚，用户体验也会更完整。