getCurrentPages()[pages.length - 1].route 是获取微信小程序当前页面路径的唯一可靠方式，返回如 "pages/index/index" 的字符串（无前缀、无后缀），且必须取数组末位；options 中的 query 参数需在 onLoad 中读取并手动解码，不可拼接构造完整路径。
getCurrentPages() 是唯一稳定、跨平台可用的方式，但不同平台行为差异大，不能直接套用同一段代码。
小程序端必须用 getCurrentPages()[0].route
微信/支付宝等小程序中，getCurrentPages() 返回的页面对象里，route 字段就是路径（如 "pages/index/index"），注意：
- 没有前导 /，也没有 .vue 后缀
- 不是 this.$route.path —— 小程序不注入 Vue Router 实例，读出来永远是空或 {}
- 也不是 this.$mp.page.route —— 虽然偶尔能取到，但在某些编译模式或真机环境下可能为 undefined，不可靠
- 页面栈顺序是「从栈底到栈顶」，当前页在末尾，所以要用 pages[pages.length - 1]，不是 [0]（除非你明确要首页）
onLoad 里优先读 options 拿参数，别拼路径
小程序页面加载时，URL 的 query 参数会自动解析为 onLoad 的第一个参数 options 对象（如 { id: "123", name: "%E4%BD%A0%E5%A5%BD" }），但：
- options 里的值**不会自动 decodeURIComponent，中文/特殊字符全是百分号编码
- 必须对每个字段手动包裹 decodeURIComponent(options.xxx || "")，并加 try/catch 防止非法编码崩溃
- 完整路径（含 query）不该靠拼接生成——容易漏转义、错格式；真正需要完整 URL 的场景（如分享、跳转），应该在跳转发起时就确定好字符串，而不是回溯构造
- 冷启动、扫码、分享卡片进入时，onLoad 的 options 才是唯一可信来源；getCurrentPages() 此时可能还没注入参数，或返回空 options
H5/APP 端走 this.$route，但别混用
H5 和 APP 平台启用 Vue Router 兼容层，this.$route.path 和 this.$route.query 可用，但：
- 小程序平台下 this.$route 是未定义的，运行时访问会报错或返回空对象
- 不要写 if (process.env.UNI_PLATFORM === 'h5') { ... } else { ... } 这类条件分支来切逻辑——维护成本高，且容易漏掉平台边界（比如快应用、头条小程序）
- 统一路由访问？封装一个工具函数，内部用 uni.getSystemInfoSync().platform 判断，但注意：小程序无法通过任何 API 反推出原始 URL 字符串，只能靠 getCurrentPages() + options 组合逼近
拼完整路径时，encodeURIComponent 必须成对出现
如果非得拼出类似 /pages/detail/detail?id=123&name=%E4%BD%A0%E5%A5%BD 的字符串（例如用于 uni.navigateTo 或分享）：
- key 和 value 都要单独 encodeURIComponent，不能只包 value
- 拼接前检查 options 是否为空对象，避免生成 ?& 这种非法 query
- 中文路径名（极少见）也要 encode，但 uni-app 编译后路径名通常都是英文+数字，重点防参数
- 最保险的做法：跳转时传原始参数对象，让框架内部处理编码；只有在透传给原生 SDK 或第三方服务时，才自己拼 URL
真正难的不是“怎么拿”，而是“什么时候拿对”。冷启动、分享卡片、后台唤醒、tabbar 切换，触发的生命周期和参数注入时机完全不同。很多人卡在 onShow 里反复读不到参数，其实是因为转发参数只进 onLoad，而热启动压根不触发它。
