拓冰网站定制 
上周三下午同事甩过来一个埋点需求活动页要把用户当前所在页面的完整 url 和参数一起上报给数据平台用来分析不同渠道进来的转化路径。我第一反应是「这不简单」结果写了三版才把边角情况兜住——扫码进来的 scene 是编码的、switchTab 之后参数全丢、分享出去再点回来参数少了一半。这篇文章就把我在微信小程序里获取当前页面 url 和参数这件事从头到尾拆一遍包括踩过的坑和我最后沉淀下来的那套工具函数。不管你是刚接触微信小程序开发的新手还是已经做过几个项目但没系统梳理过路由参数的老人应该都能直接抄走用。1. 先搞清楚小程序里的 url 到底是什么东西动手写代码之前得先把概念对齐。很多人第一反应是「url 不就是浏览器地址栏那串东西吗」在小程序里这个类比只对了一半剩下的那一半恰恰是最容易出问题的地方。1.1 小程序的 url 是「路径 参数」的组合小程序的页面 url 由两部分组成页面路径和查询参数。路径是pages/detail/detail这种形式不带前导斜杠也不带协议和域名——因为小程序没有传统意义上的域名概念所有页面都在同一个包或分包里。查询参数就是我们熟悉的?id123fromshare这种形式用分隔用连接键值。拼接起来就是pages/detail/detail?id123fromshare。注意看前面没有斜杠。但如果你要把它写进wx.navigateTo的 url 字段或者写进onShareAppMessage的 path 字段就必须补上前导斜杠变成/pages/detail/detail?id123fromshare。这个细节很坑人——getCurrentPages()拿到的 route 是不带斜杠的直接拿去跳转或分享部分场景会静默失败你连报错都看不到。我一般习惯在工具函数里统一处理内部存储用不带斜杠的形式跟官方一致对外输出跳转、分享、上报统一补斜杠。这样两边都不会记混。1.2 为什么不能像网页那样直接读 location网页里一行window.location.href就搞定了小程序里没有window也没有location。这是很多人从 H5 转小程序时的第一个认知落差。小程序是双线程架构逻辑层跑在 JSCore 里视图层跑在另一个线程渲染层根本没有可以随便访问的全局对象。但小程序给了我们一个替代品页面栈。官方提供了getCurrentPages()这个全局函数返回当前页面栈的实例数组。数组的最后一个元素就是当前显示的页面第一个元素是首页。有了这个数组我们就能反推出当前页面的路径和参数甚至能拿到上几层页面的信息。这个函数就是整件事的核心钥匙后面所有方案都围绕它展开。1.3 适合谁看能解决哪些具体问题这套东西解决的场景其实很集中埋点上报需要完整 url、分享卡片需要把当前页参数原样带出去、返回上一页需要把结果回传、扫码进入需要解析 scene、跨页面跳转需要校验参数合法性。如果你的项目里出现过「分享出去的链接点进来参数没了」「tabBar 页面之间跳转参数传不过去」这类问题那基本就是路由参数没处理干净。代码量不大一个百来行的工具文件就能覆盖九成场景但每一个细节都得想清楚否则就是线上偶发 bug 的温床。下面我从最基础的取法讲起一路讲到完整的封装方案。2. getCurrentPages 拿路径和参数的正确姿势getCurrentPages()本身很简单一行调用就返回数组。但返回的页面实例上到底有哪些字段能用、哪些字段可靠这里面的水比较深值得单独拆开说。2.1 页面实例上到底有哪些可用字段调用getCurrentPages()之后数组里每个元素都是对应页面的 Page 实例。上面比较有用的字段有三个route是页面路径字符串不带前导斜杠比如pages/index/indexoptions是页面参数对象键值对形式还有就是页面自己的data你在 onLoad 里 setData 进去的东西都能读到。route这个字段基本是稳的从早期基础库到现在都能用。但options就要小心了——它在很多基础库版本上确实存在能直接读到跳转时传进来的参数但官方文档并没有把它作为一个明确承诺的稳定 API 来维护。我在项目里遇到过某次基础库升级后某个低版本机型上options返回空对象的情况排查了大半天。所以我的建议是options可以读但不要作为唯一数据源。更稳的做法是在onLoad(options)的回调里把参数手动存一份到页面实例的自定义属性或者data里。onLoad的参数是官方明确保证的永远不会失效。2.2 三种取参方式的实际对比我把常见的三种写法整理成了一张表你可以对照自己项目的需求选方式数据来源可靠性适用场景onLoad 回调参数官方文档明确保证最高页面初始化时解析参数页面实例的 options基础库实现细节中等跨页面读取、工具函数内取值自行缓存到 data开发者自己维护最高需要在 onShow 等后续生命周期使用从表格能看出来onLoad和自行缓存是两条最稳的路。实际项目里我通常是组合使用onLoad里解析一次把结果标准化后存到data.params或者页面实例的this.$params上后续任何地方要用就直接读缓存。工具函数里需要跨页面取值时才去读页面实例的options作为兜底。这里还有个顺序问题。getCurrentPages()在App.onLaunch阶段调用会返回空数组因为那时候还没有任何页面入栈。同理在onLoad的极早期调用当前页可能还没完全入栈。实践下来在onReady及之后调用是最保险的。2.3 一个最小可用的取 url 函数先给一个最小版本方便你快速验证思路function getCurrentPageUrl() { const pages getCurrentPages() if (!pages || pages.length 0) return const page pages[pages.length - 1] const route page.route || const options page.options || {} const query Object.keys(options) .filter(key options[key] ! undefined options[key] ! null) .map(key ${encodeURIComponent(key)}${encodeURIComponent(options[key])}) .join() return query ? /${route}?${query} : /${route} }这段代码有三个细节值得展开。第一pages[pages.length - 1]取的是栈顶也就是当前页面别写成pages[0]。第二参数拼接时必须做encodeURIComponent否则参数值里如果带或者拼出来的 url 结构就乱了。第三过滤掉undefined和null的键避免拼出?idundefined这种脏数据。还有一个容易忽略的点route前面我手动补了斜杠。因为对外输出分享、跳转、上报几乎都要求带斜杠的形式在这里统一补上比在每个调用点补要省心得多。3. 不同进入方式下参数从哪来同样是打开一个页面用户可能从站内跳转进来可能扫小程序码进来也可能点别人分享的卡片进来。这几种方式在onLoad的参数形态上差别很大如果只按最普通的情况写代码线上必然出问题。3.1 站内跳转navigateTo 与 eventChannel站内跳转是最标准的场景。wx.navigateTo({ url: /pages/detail/detail?id1fromlist })目标页onLoad(options)里就能拿到{ id: 1, from: list }。注意所有参数值都是字符串类型id拿到的是1不是1如果需要数字记得手动转换这点在跟后端接口对接时特别容易出错——我见过把字符串0当数值判断为真的 bug。如果参数比较复杂比如要传一个对象有两个选择。一是序列化后传JSON.stringify再encodeURIComponent接收端反向操作。二是用eventChannel这是navigateTo独有的能力通过events定义回调在目标页onLoad里通过this.getOpenerEventChannel()拿到通道然后emit数据。对象结构复杂、数据量大的时候我倾向于用eventChannel省去了序列化反序列化的麻烦也不会因为 url 太长触发长度限制。3.2 扫码进入scene 参数必须解码扫普通链接二维码或者小程序码进入的时候情况就变了。普通链接二维码里配置的参数会正常出现在onLoad的options里但小程序码用的scene字段是个特殊通道——它整个是经过编码的onLoad(options)里拿到的options.scene是一串编码后的字符串。常见处理方式是这样onLoad(options) { let scene options.scene || if (scene) { scene decodeURIComponent(scene) } // scene 常见格式是 id123fromqr 或者直接是 123 const sceneParams parseQuery(scene) console.log(sceneParams) }这里要注意scene有长度限制最多 32 个可见字符所以不要想着往里面塞很多东西。复杂场景一般是塞一个短 ID进入页面后再拿这个 ID 去请求详情。另外decodeURIComponent可能因为非法编码串抛异常稳妥的做法是包一层 try/catch解码失败就直接用原串兜底。3.3 分享转发路径要自己拼分享是最容易丢参数的入口。onShareAppMessage返回的path必须由你自己拼不写就是默认的当前页路径——而默认拼接出来的路径不带任何参数。所以如果用户是从分享卡片进来的参数就全丢了。正确写法是把当前页的参数原样带出去onShareAppMessage() { const pages getCurrentPages() const current pages[pages.length - 1] const options current.options || {} const query Object.keys(options) .map(k ${encodeURIComponent(k)}${encodeURIComponent(options[k])}) .join() return { title: 我分享了一个好物, path: /pages/detail/detail${query ? ? query : } } }这里有个坑特别隐蔽如果参数值本身就是一个带 query 的 url比如从活动页跳详情页时把落地页地址当参数传那么分享出去再进来时接收方decodeURIComponent一次之后参数会被再次切分导致参数被截断。解决办法是两次编码发送端encodeURIComponent两次接收端相应地decodeURIComponent两次。什么时候需要两次编码判断标准很简单——你的参数值里会不会出现、、?这些 url 保留字符。会就编两次。3.4 switchTab 场景参数是真的传不过去tabBar 页面之间的跳转用wx.switchTab而它不支持在 url 上带参数。你写了参数也会被忽略某些基础库版本甚至直接报错。这不是 bug是设计如此——tabBar 页面被设计成常驻页面切换时走的是onShow而不是onLoad。要跨 tabBar 传参能用的方案有三个全局变量在app.globalData上挂一个字段发送方写、接收方在onShow里读读完就清掉避免脏数据。本地存储wx.setStorageSync写、读、删。适合数据量稍大或者需要跨启动周期保留的情况。事件总线自己实现一个简单的发布订阅或者用第三方库。适合多页面同时在监听同一个事件的场景。我个人最常用的是全局变量方案简单直接配合「用完即清」的约定基本不会出问题。但要特别注意清理时机——如果在onShow里读了但没清用户下次再切回来还会读到旧值。4. 参数编码解码的那些坑编码问题是路由参数里最磨人的部分。它不像语法错误那样直接报错而是表现为「参数偶尔不对」「某些用户的数据错乱」排查成本极高。4.1 一次编码和两次编码的边界在哪先说结论在 url 上传参参数值一定要编码参数值本身就是 url 的时候一定要编两次。假设我们要把https://example.com/a?x1y2作为参数target传给详情页。如果只编码一次拼出来的 url 是/pages/detail/detail?targethttps%3A%2F%2Fexample.com%2Fa%3Fx%3D1%26y%3D2接收端options.target会得到https://example.com/a?x1y2看起来没问题。但如果这个页面再分享一次分享的 path 又把这个值编码进新的 url接收端解码一次之后options解析器会先按切分参数y2就变成了独立参数target被截断成https://example.com/a?x1。这就是最典型的「分享一次就坏」的场景。两次编码就是把这个过程包两层接收端解两次中间层的解析就切不断了。反过来什么时候只需要一次编码参数值是普通字符串不含 url 保留字符的时候一次就够。过度编码会让参数看起来像乱码也没必要。4.2 中文、空格和特殊符号的处理encodeURIComponent对中文和空格都是安全的中文会变成%E4%B8%AD%E6%96%87这样的形式空格变成%20。真正麻烦的是那些看起来无害的符号在某些解析器里会被当成空格还原#会截断后面的所有内容%如果后面不是合法的两位十六进制会直接抛URIError。所以接收端解码时我一般会加保护function safeDecode(str) { if (typeof str ! string) return try { return decodeURIComponent(str) } catch (e) { // 遇见非法编码串原样返回避免整个页面白屏 return str } }页面白屏是这类异常最严重的后果——onLoad里抛异常会导致页面初始化中断。一个解码失败就废掉整个页面性价比太低了所以这个 try/catch 是我认为必须加的。4.3 参数合法性校验函数从 url 里拿到的参数全都是不可信的尤其是有分享链路的时候谁都能构造一个带奇怪参数的链接。所以进入页面前最好做一层校验。校验分两种。第一种是格式校验比如 ID 必须是数字、必须是 20 位以内的字符串function checkId(raw) { const id String(raw || ).trim() if (!/^\d{1,20}$/.test(id)) return null return id }第二种是 url 有效性校验这个在接收 url 类参数时很有用。思路是先用正则粗筛协议和结构再用new URL()试构造一次function isValidUrl(str) { if (typeof str ! string || !str) return false if (!/^https?:\/\//i.test(str)) return false try { const u new URL(str) return !!u.hostname } catch (e) { return false } }注意new URL在小程序的 JS 环境里是支持的但只在较新的基础库版本上。如果你的项目要兼容很老的基础库就用正则做完整校验别依赖这个构造函数。校验失败的处理策略也很重要——不要直接白屏或者弹错误提示最好是降级到一个默认页或者兜底数据用户体验会好很多。5. 常见问题速查与排查思路这部分是我这两年在项目里真实遇到的问题汇总按「现象」组织方便你遇到问题的时候直接对号入座。现象大概率原因排查动作options 是空对象基础库版本差异或页面未完成入栈在 onReady 里打印改用 onLoad 缓存分享进来参数丢失onShareAppMessage 没拼 path打印返回对象确认 path 含 query参数被截断只做了一次编码值里含改成两次编码接收端解两次中文参数乱码发送或接收端缺少编解码统一在发送端 encode接收端 decodeswitchTab 拿不到参数框架设计限制改用 globalData 或 storage 传递拿到 undefined参数值本身为空被过滤检查发送端是否传了空值页面栈取到错误的页页面栈层级多索引写错统一用 length - 1 取当前页getCurrentPages 返回空在 App.onLaunch 阶段调用延后到页面 onReady 之后表格之外再补充几个口头经验。第一个经验永远在 onLoad 里把参数快照存一份。这是最简单也最有效的防御手段成本只有一行代码收益是后续任何生命周期都能拿到参数。我现在的项目里每个页面onLoad的第一件事就是this.$params { ...options }。第二个经验上报埋点要用自己拼的 url不要依赖框架。埋点平台要的是完整路径加参数而这个东西只有你能拼准确。我习惯在onShow里触发一次上报同时做一次去重——同一个页面反复onShow不要重复上报否则数据会被污染得很厉害。第三个经验页面栈最深 10 层。小程序的页面栈限制是 10 层超过之后navigateTo会失败。如果你的应用有很深的跳转链路比如列表进详情详情再进相关推荐一路点下去一定要在关键位置用redirectTo替换或者做页面栈深度的监控。这个坑爆发的时候表现是「点了没反应」非常难定位。第四个经验做一层路由参数的统一入口。不要在每个页面的onLoad里散落着写解析逻辑而是写一个parsePageOptions(options, schema)之类的函数页面上只声明需要哪些参数、什么类型、默认值是什么解析和校验都交给函数处理。这样参数格式变了只需要改一处。6. 封装一套能直接抄走的路由参数工具前面讲的都是点上的问题最后给一份我在项目里实际用的封装。文件名叫router-params.js核心就是几个函数你可以整体拷过去也可以按需摘取。6.1 工具函数完整实现// 安全解码 function safeDecode(str) { if (typeof str ! string) return try { return decodeURIComponent(str) } catch (e) { return str } } // 解析 query 字符串为对象支持自定义解码次数 function parseQuery(queryStr, decodeTimes 1) { const result {} if (!queryStr || typeof queryStr ! string) return result const pairs queryStr.split() for (const pair of pairs) { if (!pair) continue const idx pair.indexOf() const key idx -1 ? pair : pair.slice(0, idx) let value idx -1 ? : pair.slice(idx 1) for (let i 0; i decodeTimes; i) { value safeDecode(value) } result[decodeTimes 0 ? safeDecode(key) : key] value } return result } // 对象转 query 字符串 function stringifyQuery(params, encodeTimes 1) { if (!params || typeof params ! object) return return Object.keys(params) .filter(k params[k] ! undefined params[k] ! null) .map(k { let value String(params[k]) for (let i 0; i encodeTimes; i) { value encodeURIComponent(value) } return ${encodeURIComponent(k)}${value} }) .join() } // 获取当前页面栈顶实例 function getCurrentPage() { const pages getCurrentPages() if (!pages || !pages.length) return null return pages[pages.length - 1] } // 获取当前页面路径带前导斜杠 function getCurrentRoute() { const page getCurrentPage() if (!page || !page.route) return return / page.route.replace(/^\//, ) } // 获取当前页面参数对象优先用缓存 function getCurrentParams() { const page getCurrentPage() if (!page) return {} if (page.$params typeof page.$params object) { return { ...page.$params } } if (page.options typeof page.options object) { return { ...page.options } } return {} } // 获取当前页面完整 url带前导斜杠 function getCurrentUrl(encodeTimes 1) { const route getCurrentRoute() if (!route) return const query stringifyQuery(getCurrentParams(), encodeTimes) return query ? ${route}?${query} : route } // 获取上一页的完整 url function getPrevUrl() { const pages getCurrentPages() if (!pages || pages.length 2) return const prev pages[pages.length - 2] const route prev prev.route ? / prev.route.replace(/^\//, ) : if (!route) return const params (prev.$params || prev.options || {}) const query stringifyQuery(params) return query ? ${route}?${query} : route } // 参数校验按 schema 提取并转换 function pickParams(raw, schema) { const out {} const src raw || {} for (const key of Object.keys(schema)) { const rule schema[key] let value src[key] if (value undefined || value null || value ) { out[key] rule.default ! undefined ? rule.default : null continue } if (rule.type number) { const num Number(value) out[key] Number.isNaN(num) ? (rule.default ! undefined ? rule.default : null) : num } else if (rule.type boolean) { out[key] value true || value 1 || value true } else { out[key] rule.decode ? safeDecode(String(value)) : String(value) } } return out } module.exports { safeDecode, parseQuery, stringifyQuery, getCurrentPage, getCurrentRoute, getCurrentParams, getCurrentUrl, getPrevUrl, pickParams }6.2 在页面里怎么用工具写好之后页面里的代码可以瘦到很少。onLoad里只做两件事存快照、按 schema 提取参数。const routerParams require(../../utils/router-params) Page({ onLoad(options) { // 第一件事存快照后续任何生命周期都能读 this.$params { ...options } // 第二件事按声明式 schema 提取 const params routerParams.pickParams(options, { id: { type: number, default: 0 }, from: { type: string, default: unknown }, target: { type: string, decode: true } }) console.log(解析后的参数, params) this.setData({ params }) }, onShow() { // 埋点上报完整 url const url routerParams.getCurrentUrl() console.log(当前页面 url, url) // reportPageView(url) }, onShareAppMessage() { return { title: 分享标题, path: routerParams.getCurrentUrl() } } })这套写法有几个明显的好处。参数解析逻辑集中在一个地方类型转换和默认值都在 schema 里声明页面代码只关心业务。getCurrentUrl()在onShow、onShareAppMessage、埋点上报这些地方可以直接复用不需要每个页面各写一遍拼接逻辑。上一页 url 的获取也有了统一入口做返回链路分析的时候很方便。6.3 使用这套工具时的几个约定工具本身没什么理解门槛但有几条约定需要在团队里对齐否则用起来还是会乱。第一this.$params是页面级的约定字段不要往这个字段上塞别的东西。工具函数内部会优先读它一旦被污染getCurrentUrl()返回的数据就不准了。第二编码次数要成对出现。发送端stringifyQuery传了几次接收端解析时就要对应几次。我一般约定普通参数用一次已知值是 url 的参数用两次写在页面注释里避免后面接手的人搞混。第三不要在App.onLaunch里调用页面栈相关的函数。那时候页面栈是空的拿到的永远是空字符串。如果确实需要在启动阶段记录什么用wx.getLaunchOptionsSync()拿启动参数那是另一套东西不要跟页面栈混着用。第四埋点去重要自己做。onShow会在页面每次展示时触发从详情页返回列表页也会触发如果不做去重同一个页面的上报量会明显偏高。我一般的做法是在页面实例上记一个上次上报的 url相同时跳过。最后分享一个我在实际项目中反复验证过的小技巧调试路由参数的时候别只用真机或者模拟器点来点去直接在app.js或者某个公共位置挂一个全局方法把getCurrentPages()的完整信息格式化打印出来包括每一层的 route、options 和自定义缓存字段。页面栈超过三层之后肉眼是很难跟踪参数到底在哪一层丢掉的有这么一份完整的快照排查效率能提升一大截。 微信小程序获取当前页面 URL 与参数：getCurrentPages 路由实践
上周三下午同事甩过来一个埋点需求活动页要把用户当前所在页面的完整 url 和参数一起上报给数据平台用来分析不同渠道进来的转化路径。我第一反应是「这不简单」结果写了三版才把边角情况兜住——扫码进来的 scene 是编码的、switchTab 之后参数全丢、分享出去再点回来参数少了一半。这篇文章就把我在微信小程序里获取当前页面 url 和参数这件事从头到尾拆一遍包括踩过的坑和我最后沉淀下来的那套工具函数。不管你是刚接触微信小程序开发的新手还是已经做过几个项目但没系统梳理过路由参数的老人应该都能直接抄走用。1. 先搞清楚小程序里的 url 到底是什么东西动手写代码之前得先把概念对齐。很多人第一反应是「url 不就是浏览器地址栏那串东西吗」在小程序里这个类比只对了一半剩下的那一半恰恰是最容易出问题的地方。1.1 小程序的 url 是「路径 参数」的组合小程序的页面 url 由两部分组成页面路径和查询参数。路径是pages/detail/detail这种形式不带前导斜杠也不带协议和域名——因为小程序没有传统意义上的域名概念所有页面都在同一个包或分包里。查询参数就是我们熟悉的?id123fromshare这种形式用分隔用连接键值。拼接起来就是pages/detail/detail?id123fromshare。注意看前面没有斜杠。但如果你要把它写进wx.navigateTo的 url 字段或者写进onShareAppMessage的 path 字段就必须补上前导斜杠变成/pages/detail/detail?id123fromshare。这个细节很坑人——getCurrentPages()拿到的 route 是不带斜杠的直接拿去跳转或分享部分场景会静默失败你连报错都看不到。我一般习惯在工具函数里统一处理内部存储用不带斜杠的形式跟官方一致对外输出跳转、分享、上报统一补斜杠。这样两边都不会记混。1.2 为什么不能像网页那样直接读 location网页里一行window.location.href就搞定了小程序里没有window也没有location。这是很多人从 H5 转小程序时的第一个认知落差。小程序是双线程架构逻辑层跑在 JSCore 里视图层跑在另一个线程渲染层根本没有可以随便访问的全局对象。但小程序给了我们一个替代品页面栈。官方提供了getCurrentPages()这个全局函数返回当前页面栈的实例数组。数组的最后一个元素就是当前显示的页面第一个元素是首页。有了这个数组我们就能反推出当前页面的路径和参数甚至能拿到上几层页面的信息。这个函数就是整件事的核心钥匙后面所有方案都围绕它展开。1.3 适合谁看能解决哪些具体问题这套东西解决的场景其实很集中埋点上报需要完整 url、分享卡片需要把当前页参数原样带出去、返回上一页需要把结果回传、扫码进入需要解析 scene、跨页面跳转需要校验参数合法性。如果你的项目里出现过「分享出去的链接点进来参数没了」「tabBar 页面之间跳转参数传不过去」这类问题那基本就是路由参数没处理干净。代码量不大一个百来行的工具文件就能覆盖九成场景但每一个细节都得想清楚否则就是线上偶发 bug 的温床。下面我从最基础的取法讲起一路讲到完整的封装方案。2. getCurrentPages 拿路径和参数的正确姿势getCurrentPages()本身很简单一行调用就返回数组。但返回的页面实例上到底有哪些字段能用、哪些字段可靠这里面的水比较深值得单独拆开说。2.1 页面实例上到底有哪些可用字段调用getCurrentPages()之后数组里每个元素都是对应页面的 Page 实例。上面比较有用的字段有三个route是页面路径字符串不带前导斜杠比如pages/index/indexoptions是页面参数对象键值对形式还有就是页面自己的data你在 onLoad 里 setData 进去的东西都能读到。route这个字段基本是稳的从早期基础库到现在都能用。但options就要小心了——它在很多基础库版本上确实存在能直接读到跳转时传进来的参数但官方文档并没有把它作为一个明确承诺的稳定 API 来维护。我在项目里遇到过某次基础库升级后某个低版本机型上options返回空对象的情况排查了大半天。所以我的建议是options可以读但不要作为唯一数据源。更稳的做法是在onLoad(options)的回调里把参数手动存一份到页面实例的自定义属性或者data里。onLoad的参数是官方明确保证的永远不会失效。2.2 三种取参方式的实际对比我把常见的三种写法整理成了一张表你可以对照自己项目的需求选方式数据来源可靠性适用场景onLoad 回调参数官方文档明确保证最高页面初始化时解析参数页面实例的 options基础库实现细节中等跨页面读取、工具函数内取值自行缓存到 data开发者自己维护最高需要在 onShow 等后续生命周期使用从表格能看出来onLoad和自行缓存是两条最稳的路。实际项目里我通常是组合使用onLoad里解析一次把结果标准化后存到data.params或者页面实例的this.$params上后续任何地方要用就直接读缓存。工具函数里需要跨页面取值时才去读页面实例的options作为兜底。这里还有个顺序问题。getCurrentPages()在App.onLaunch阶段调用会返回空数组因为那时候还没有任何页面入栈。同理在onLoad的极早期调用当前页可能还没完全入栈。实践下来在onReady及之后调用是最保险的。2.3 一个最小可用的取 url 函数先给一个最小版本方便你快速验证思路function getCurrentPageUrl() { const pages getCurrentPages() if (!pages || pages.length 0) return const page pages[pages.length - 1] const route page.route || const options page.options || {} const query Object.keys(options) .filter(key options[key] ! undefined options[key] ! null) .map(key ${encodeURIComponent(key)}${encodeURIComponent(options[key])}) .join() return query ? /${route}?${query} : /${route} }这段代码有三个细节值得展开。第一pages[pages.length - 1]取的是栈顶也就是当前页面别写成pages[0]。第二参数拼接时必须做encodeURIComponent否则参数值里如果带或者拼出来的 url 结构就乱了。第三过滤掉undefined和null的键避免拼出?idundefined这种脏数据。还有一个容易忽略的点route前面我手动补了斜杠。因为对外输出分享、跳转、上报几乎都要求带斜杠的形式在这里统一补上比在每个调用点补要省心得多。3. 不同进入方式下参数从哪来同样是打开一个页面用户可能从站内跳转进来可能扫小程序码进来也可能点别人分享的卡片进来。这几种方式在onLoad的参数形态上差别很大如果只按最普通的情况写代码线上必然出问题。3.1 站内跳转navigateTo 与 eventChannel站内跳转是最标准的场景。wx.navigateTo({ url: /pages/detail/detail?id1fromlist })目标页onLoad(options)里就能拿到{ id: 1, from: list }。注意所有参数值都是字符串类型id拿到的是1不是1如果需要数字记得手动转换这点在跟后端接口对接时特别容易出错——我见过把字符串0当数值判断为真的 bug。如果参数比较复杂比如要传一个对象有两个选择。一是序列化后传JSON.stringify再encodeURIComponent接收端反向操作。二是用eventChannel这是navigateTo独有的能力通过events定义回调在目标页onLoad里通过this.getOpenerEventChannel()拿到通道然后emit数据。对象结构复杂、数据量大的时候我倾向于用eventChannel省去了序列化反序列化的麻烦也不会因为 url 太长触发长度限制。3.2 扫码进入scene 参数必须解码扫普通链接二维码或者小程序码进入的时候情况就变了。普通链接二维码里配置的参数会正常出现在onLoad的options里但小程序码用的scene字段是个特殊通道——它整个是经过编码的onLoad(options)里拿到的options.scene是一串编码后的字符串。常见处理方式是这样onLoad(options) { let scene options.scene || if (scene) { scene decodeURIComponent(scene) } // scene 常见格式是 id123fromqr 或者直接是 123 const sceneParams parseQuery(scene) console.log(sceneParams) }这里要注意scene有长度限制最多 32 个可见字符所以不要想着往里面塞很多东西。复杂场景一般是塞一个短 ID进入页面后再拿这个 ID 去请求详情。另外decodeURIComponent可能因为非法编码串抛异常稳妥的做法是包一层 try/catch解码失败就直接用原串兜底。3.3 分享转发路径要自己拼分享是最容易丢参数的入口。onShareAppMessage返回的path必须由你自己拼不写就是默认的当前页路径——而默认拼接出来的路径不带任何参数。所以如果用户是从分享卡片进来的参数就全丢了。正确写法是把当前页的参数原样带出去onShareAppMessage() { const pages getCurrentPages() const current pages[pages.length - 1] const options current.options || {} const query Object.keys(options) .map(k ${encodeURIComponent(k)}${encodeURIComponent(options[k])}) .join() return { title: 我分享了一个好物, path: /pages/detail/detail${query ? ? query : } } }这里有个坑特别隐蔽如果参数值本身就是一个带 query 的 url比如从活动页跳详情页时把落地页地址当参数传那么分享出去再进来时接收方decodeURIComponent一次之后参数会被再次切分导致参数被截断。解决办法是两次编码发送端encodeURIComponent两次接收端相应地decodeURIComponent两次。什么时候需要两次编码判断标准很简单——你的参数值里会不会出现、、?这些 url 保留字符。会就编两次。3.4 switchTab 场景参数是真的传不过去tabBar 页面之间的跳转用wx.switchTab而它不支持在 url 上带参数。你写了参数也会被忽略某些基础库版本甚至直接报错。这不是 bug是设计如此——tabBar 页面被设计成常驻页面切换时走的是onShow而不是onLoad。要跨 tabBar 传参能用的方案有三个全局变量在app.globalData上挂一个字段发送方写、接收方在onShow里读读完就清掉避免脏数据。本地存储wx.setStorageSync写、读、删。适合数据量稍大或者需要跨启动周期保留的情况。事件总线自己实现一个简单的发布订阅或者用第三方库。适合多页面同时在监听同一个事件的场景。我个人最常用的是全局变量方案简单直接配合「用完即清」的约定基本不会出问题。但要特别注意清理时机——如果在onShow里读了但没清用户下次再切回来还会读到旧值。4. 参数编码解码的那些坑编码问题是路由参数里最磨人的部分。它不像语法错误那样直接报错而是表现为「参数偶尔不对」「某些用户的数据错乱」排查成本极高。4.1 一次编码和两次编码的边界在哪先说结论在 url 上传参参数值一定要编码参数值本身就是 url 的时候一定要编两次。假设我们要把https://example.com/a?x1y2作为参数target传给详情页。如果只编码一次拼出来的 url 是/pages/detail/detail?targethttps%3A%2F%2Fexample.com%2Fa%3Fx%3D1%26y%3D2接收端options.target会得到https://example.com/a?x1y2看起来没问题。但如果这个页面再分享一次分享的 path 又把这个值编码进新的 url接收端解码一次之后options解析器会先按切分参数y2就变成了独立参数target被截断成https://example.com/a?x1。这就是最典型的「分享一次就坏」的场景。两次编码就是把这个过程包两层接收端解两次中间层的解析就切不断了。反过来什么时候只需要一次编码参数值是普通字符串不含 url 保留字符的时候一次就够。过度编码会让参数看起来像乱码也没必要。4.2 中文、空格和特殊符号的处理encodeURIComponent对中文和空格都是安全的中文会变成%E4%B8%AD%E6%96%87这样的形式空格变成%20。真正麻烦的是那些看起来无害的符号在某些解析器里会被当成空格还原#会截断后面的所有内容%如果后面不是合法的两位十六进制会直接抛URIError。所以接收端解码时我一般会加保护function safeDecode(str) { if (typeof str ! string) return try { return decodeURIComponent(str) } catch (e) { // 遇见非法编码串原样返回避免整个页面白屏 return str } }页面白屏是这类异常最严重的后果——onLoad里抛异常会导致页面初始化中断。一个解码失败就废掉整个页面性价比太低了所以这个 try/catch 是我认为必须加的。4.3 参数合法性校验函数从 url 里拿到的参数全都是不可信的尤其是有分享链路的时候谁都能构造一个带奇怪参数的链接。所以进入页面前最好做一层校验。校验分两种。第一种是格式校验比如 ID 必须是数字、必须是 20 位以内的字符串function checkId(raw) { const id String(raw || ).trim() if (!/^\d{1,20}$/.test(id)) return null return id }第二种是 url 有效性校验这个在接收 url 类参数时很有用。思路是先用正则粗筛协议和结构再用new URL()试构造一次function isValidUrl(str) { if (typeof str ! string || !str) return false if (!/^https?:\/\//i.test(str)) return false try { const u new URL(str) return !!u.hostname } catch (e) { return false } }注意new URL在小程序的 JS 环境里是支持的但只在较新的基础库版本上。如果你的项目要兼容很老的基础库就用正则做完整校验别依赖这个构造函数。校验失败的处理策略也很重要——不要直接白屏或者弹错误提示最好是降级到一个默认页或者兜底数据用户体验会好很多。5. 常见问题速查与排查思路这部分是我这两年在项目里真实遇到的问题汇总按「现象」组织方便你遇到问题的时候直接对号入座。现象大概率原因排查动作options 是空对象基础库版本差异或页面未完成入栈在 onReady 里打印改用 onLoad 缓存分享进来参数丢失onShareAppMessage 没拼 path打印返回对象确认 path 含 query参数被截断只做了一次编码值里含改成两次编码接收端解两次中文参数乱码发送或接收端缺少编解码统一在发送端 encode接收端 decodeswitchTab 拿不到参数框架设计限制改用 globalData 或 storage 传递拿到 undefined参数值本身为空被过滤检查发送端是否传了空值页面栈取到错误的页页面栈层级多索引写错统一用 length - 1 取当前页getCurrentPages 返回空在 App.onLaunch 阶段调用延后到页面 onReady 之后表格之外再补充几个口头经验。第一个经验永远在 onLoad 里把参数快照存一份。这是最简单也最有效的防御手段成本只有一行代码收益是后续任何生命周期都能拿到参数。我现在的项目里每个页面onLoad的第一件事就是this.$params { ...options }。第二个经验上报埋点要用自己拼的 url不要依赖框架。埋点平台要的是完整路径加参数而这个东西只有你能拼准确。我习惯在onShow里触发一次上报同时做一次去重——同一个页面反复onShow不要重复上报否则数据会被污染得很厉害。第三个经验页面栈最深 10 层。小程序的页面栈限制是 10 层超过之后navigateTo会失败。如果你的应用有很深的跳转链路比如列表进详情详情再进相关推荐一路点下去一定要在关键位置用redirectTo替换或者做页面栈深度的监控。这个坑爆发的时候表现是「点了没反应」非常难定位。第四个经验做一层路由参数的统一入口。不要在每个页面的onLoad里散落着写解析逻辑而是写一个parsePageOptions(options, schema)之类的函数页面上只声明需要哪些参数、什么类型、默认值是什么解析和校验都交给函数处理。这样参数格式变了只需要改一处。6. 封装一套能直接抄走的路由参数工具前面讲的都是点上的问题最后给一份我在项目里实际用的封装。文件名叫router-params.js核心就是几个函数你可以整体拷过去也可以按需摘取。6.1 工具函数完整实现// 安全解码 function safeDecode(str) { if (typeof str ! string) return try { return decodeURIComponent(str) } catch (e) { return str } } // 解析 query 字符串为对象支持自定义解码次数 function parseQuery(queryStr, decodeTimes 1) { const result {} if (!queryStr || typeof queryStr ! string) return result const pairs queryStr.split() for (const pair of pairs) { if (!pair) continue const idx pair.indexOf() const key idx -1 ? pair : pair.slice(0, idx) let value idx -1 ? : pair.slice(idx 1) for (let i 0; i decodeTimes; i) { value safeDecode(value) } result[decodeTimes 0 ? safeDecode(key) : key] value } return result } // 对象转 query 字符串 function stringifyQuery(params, encodeTimes 1) { if (!params || typeof params ! object) return return Object.keys(params) .filter(k params[k] ! undefined params[k] ! null) .map(k { let value String(params[k]) for (let i 0; i encodeTimes; i) { value encodeURIComponent(value) } return ${encodeURIComponent(k)}${value} }) .join() } // 获取当前页面栈顶实例 function getCurrentPage() { const pages getCurrentPages() if (!pages || !pages.length) return null return pages[pages.length - 1] } // 获取当前页面路径带前导斜杠 function getCurrentRoute() { const page getCurrentPage() if (!page || !page.route) return return / page.route.replace(/^\//, ) } // 获取当前页面参数对象优先用缓存 function getCurrentParams() { const page getCurrentPage() if (!page) return {} if (page.$params typeof page.$params object) { return { ...page.$params } } if (page.options typeof page.options object) { return { ...page.options } } return {} } // 获取当前页面完整 url带前导斜杠 function getCurrentUrl(encodeTimes 1) { const route getCurrentRoute() if (!route) return const query stringifyQuery(getCurrentParams(), encodeTimes) return query ? ${route}?${query} : route } // 获取上一页的完整 url function getPrevUrl() { const pages getCurrentPages() if (!pages || pages.length 2) return const prev pages[pages.length - 2] const route prev prev.route ? / prev.route.replace(/^\//, ) : if (!route) return const params (prev.$params || prev.options || {}) const query stringifyQuery(params) return query ? ${route}?${query} : route } // 参数校验按 schema 提取并转换 function pickParams(raw, schema) { const out {} const src raw || {} for (const key of Object.keys(schema)) { const rule schema[key] let value src[key] if (value undefined || value null || value ) { out[key] rule.default ! undefined ? rule.default : null continue } if (rule.type number) { const num Number(value) out[key] Number.isNaN(num) ? (rule.default ! undefined ? rule.default : null) : num } else if (rule.type boolean) { out[key] value true || value 1 || value true } else { out[key] rule.decode ? safeDecode(String(value)) : String(value) } } return out } module.exports { safeDecode, parseQuery, stringifyQuery, getCurrentPage, getCurrentRoute, getCurrentParams, getCurrentUrl, getPrevUrl, pickParams }6.2 在页面里怎么用工具写好之后页面里的代码可以瘦到很少。onLoad里只做两件事存快照、按 schema 提取参数。const routerParams require(../../utils/router-params) Page({ onLoad(options) { // 第一件事存快照后续任何生命周期都能读 this.$params { ...options } // 第二件事按声明式 schema 提取 const params routerParams.pickParams(options, { id: { type: number, default: 0 }, from: { type: string, default: unknown }, target: { type: string, decode: true } }) console.log(解析后的参数, params) this.setData({ params }) }, onShow() { // 埋点上报完整 url const url routerParams.getCurrentUrl() console.log(当前页面 url, url) // reportPageView(url) }, onShareAppMessage() { return { title: 分享标题, path: routerParams.getCurrentUrl() } } })这套写法有几个明显的好处。参数解析逻辑集中在一个地方类型转换和默认值都在 schema 里声明页面代码只关心业务。getCurrentUrl()在onShow、onShareAppMessage、埋点上报这些地方可以直接复用不需要每个页面各写一遍拼接逻辑。上一页 url 的获取也有了统一入口做返回链路分析的时候很方便。6.3 使用这套工具时的几个约定工具本身没什么理解门槛但有几条约定需要在团队里对齐否则用起来还是会乱。第一this.$params是页面级的约定字段不要往这个字段上塞别的东西。工具函数内部会优先读它一旦被污染getCurrentUrl()返回的数据就不准了。第二编码次数要成对出现。发送端stringifyQuery传了几次接收端解析时就要对应几次。我一般约定普通参数用一次已知值是 url 的参数用两次写在页面注释里避免后面接手的人搞混。第三不要在App.onLaunch里调用页面栈相关的函数。那时候页面栈是空的拿到的永远是空字符串。如果确实需要在启动阶段记录什么用wx.getLaunchOptionsSync()拿启动参数那是另一套东西不要跟页面栈混着用。第四埋点去重要自己做。onShow会在页面每次展示时触发从详情页返回列表页也会触发如果不做去重同一个页面的上报量会明显偏高。我一般的做法是在页面实例上记一个上次上报的 url相同时跳过。最后分享一个我在实际项目中反复验证过的小技巧调试路由参数的时候别只用真机或者模拟器点来点去直接在app.js或者某个公共位置挂一个全局方法把getCurrentPages()的完整信息格式化打印出来包括每一层的 route、options 和自定义缓存字段。页面栈超过三层之后肉眼是很难跟踪参数到底在哪一层丢掉的有这么一份完整的快照排查效率能提升一大截。