夜雨聆风上个月同事跑过来问了我一个问题：“uni-app 鸿蒙端跳页面传了个对象过去，接收端打出来是 [object Object]，你有遇到过吗？”
我当时正在改一个鸿蒙端商品列表的瀑布流布局，头也没抬回了句：“URL 参数没序列化吧，JSON.stringify 一下就好了。”
他沉默了两秒，然后把手机屏幕竖到我面前——代码里明明写了 JSON.stringify，接收端 JSON.parse 之后打出来的日志还是一坨 [object Object]。
我放下手里的活，开始认真看他的代码。五分钟后我也沉默了。这他妈不对劲。我还特意让他重新跑了一次，确认不是缓存或者热重载的锅——结果一模一样。
微信小程序端同样的代码跑得好好的，H5 端也没问题，唯独鸿蒙端炸了。我自己也有几个 uni-app 鸿蒙项目在跑，从来没踩过这个坑——不是因为我写得对，纯粹是我的传参习惯刚好避开了。如果你也在做 uni-app 鸿蒙端开发，八成也被这个问题坑过，或者即将被坑。
既然肉眼找不到问题，那就翻源码。
顺着调用链追
uni-app 的跨平台机制是在编译期做代码转换。你在 .vue 文件里写的 uni.navigateTo，经过 @dcloudio/uni-cli-shared 的编译器处理后，会根据目标平台替换成不同的底层实现。鸿蒙端用的是 @dcloudio/uni-mp-harmony 这个适配包。
先看 uni.navigateTo 在鸿蒙端的实际实现。代码在 node_modules/@dcloudio/uni-mp-harmony/src/api/route/navigateTo.ts（路径因版本不同可能有差异，但核心逻辑不变）：
// node_modules/@dcloudio/uni-mp-harmony/src/api/route/navigateTo.ts// uni.navigateTo 在鸿蒙端的实现（简化但保留了关键逻辑）import router from '@ohos.router';interface NavigateToOptions {url: string;events?: Record<string, (...args: any[]) => void>;success?: (res: any) => void;fail?: (err: any) => void;complete?: () => void;}export function navigateTo(options: NavigateToOptions): void {// 第一步：从 url 中拆出页面路径和查询字符串const questionMarkIndex = options.url.indexOf('?');const path = questionMarkIndex > -1? options.url.substring(0, questionMarkIndex): options.url;// 第二步：把查询字符串解析成 params 对象const params: Record<string, string> = {};if (questionMarkIndex > -1) {const queryString = options.url.substring(questionMarkIndex + 1);queryString.split('&').forEach((pair) => {const eqIndex = pair.indexOf('=');if (eqIndex > -1) {const key = decodeURIComponent(pair.substring(0, eqIndex));const value = decodeURIComponent(pair.substring(eqIndex + 1));params[key] = value; // ← 注意：value 始终是 string}});}// 第三步：调 ArkTS 原生路由router.pushUrl({url: path,params: params // 类型签名：params?: Record<string, string>}).then(() => {options.success?.({ errMsg: 'navigateTo:ok' });}).catch((err: Error) => {options.fail?.({ errMsg: 'navigateTo:fail ' + err.message });});}
追到这里其实就已经看到线索了——params 的类型是 Record<string, string>。也就是说，不管你传的是数字、布尔值还是对象，经过 URL 的查询字符串这一层之后，全变成了字符串。
但问题是：如果调用方确实做了 JSON.stringify，那到了接收端 decodeURIComponent 之后拿到的应该是一个 JSON 字符串才对，JSON.parse 不应该失败。
既然框架层的逻辑没问题，那锅只能往底层甩了。继续往下追。
追到 ArkTS 的 router.pushUrl
打开 HarmonyOS SDK 的 @ohos.router 类型声明文件，router.pushUrl 的签名是这样的：
// @ohos.router.d.ts — ArkTS 路由模块类型声明（简化）declare namespace router {interface RouterOptions {url: string;params?: Record<string, string>; // ← 看清楚：value 必须是 string}function pushUrl(options: RouterOptions): Promise<void>;function replaceUrl(options: RouterOptions): Promise<void>;function back(options?: { url?: string; params?: Record<string, string> }): Promise<void>;function getParams(): Record<string, string>; // ← 取回来也是全 string}
看到 Record<string, string> 这几个字的时候，我脑子里像过电一样——突然理解为什么同事的代码会炸了。不是因为 JSON.stringify 没生效，而是他写的代码路径根本就没走到 JSON.stringify 那一步。
问题不出在 URL 编码/解码这个环节——那个逻辑是对的。问题出在一个更隐蔽的地方：有些同学在拼 URL 的时候图省事，直接用了 + 拼接或模板字符串插值。JS 引擎碰到对象做字符串拼接，会静默调用 toString()，结果就是你在开发者工具里看到的 [object Object]。像这样：
// ❌ 这样写，JS 引擎会隐式调用 obj.toString()const product = { id: 123, name: '蓝牙耳机', price: 199 };uni.navigateTo({url: '/pages/detail/detail?data=' + product // → "?data=[object Object]"});
或者更隐蔽的写法——数据是通过变量传进来的，调用的地方以为是字符串，其实是对象：
// ❌ 接收了一个对象，没注意到类型const queryData = route.query.data; // 这里实际是对象uni.navigateTo({url: `/pages/detail/detail?info={}插值会自动调用toString()，对象就变成了[object Object]。这种 bug 在 Web 端和小程序端可能不会暴露——因为它们的参数传递机制不一样——但鸿蒙端是严格走字符串的，一碰就炸。等一下，这里我漏说一个前提。你可能会想：“那 JSON.stringify 传过去，对方 JSON.parse 不就完了？”在 Web 端和小程序端确实是这样。但鸿蒙的 router.getParams() 还有一个坑：所有 value 全部是 string 类型，即使你传的是数字，拿回来也是字符串 "123" 而不是数字 123。 微信小程序的 onLoad(options) 里，数字参数还是数字。这个差异很要命，因为你依赖类型判断的逻辑（比如 typeof params.page === 'number'）在鸿蒙端全部失效。怎么搞才不翻车知道根因之后，解决方案其实挺直白的。我在两个真实项目里试过三种路子，各有各的适用场景，没有哪个能通吃一切。先说最直接也最省事的——JSON 序列化传参。参数体积不大的时候用这个就够了，一行 encodeURIComponent 加一行 JSON.stringify，接收端对称地解回来：// 发送端const orderDetail = { id: 456, items: ['A', 'B'], total: 398 };uni.navigateTo({url: `/pages/order/order?payload=${encodeURIComponent(JSON.stringify(orderDetail))}`});// 接收端onLoad(options: any) {if (options.payload) {const order = JSON.parse(decodeURIComponent(options.payload)) as OrderDetail;console.log(order.items.length); // 2，数据完整}}日常开发里这个方案覆盖百分之八九十的场景绰绰有余。但它有两个暗坑你得心里有数：第一，URL 总长度别超过大概 2KB——鸿蒙官方文档没给明确上限，这是我跑了几十次测试自己总结的经验值，超了不报错但参数会截断；第二，JSON.stringify 天生搞不定 undefined、Date、Function 这些类型，数据静默丢失你还浑然不觉。我吃过这个亏：有一次 Date 对象序列化后变成 ISO 字符串，接收端以为还是 Date 类型，调 .getTime() 直接报错，排查了半天才发现是序列化把类型丢了。如果你的对象比较大，或者结构比较复杂，全局 store 中转比 JSON 序列化靠谱得多。不需要引入 Pinia 或 Vuex——说实话为了一个页面传参引入完整状态管理库有点杀鸡用牛刀——一个十几行的 Map 封装就够用了：// shared/page-bridge.ts — 页面间数据桥，不到 15 行class PageBridge {private cache = new Map<string, any>();put(key: string, data: any) {this.cache.set(key, data);}take(key: string): any {const data = this.cache.get(key);this.cache.delete(key); // 取完即删，防止内存积压return data;}}export const pageBridge = new PageBridge();// 发送端pageBridge.put('currentOrder', orderDetail);uni.navigateTo({ url: '/pages/order/order?id=456' });// 接收端onLoad(options: any) {const order = pageBridge.take('currentOrder') as OrderDetail;// order 是原始对象引用，Date、嵌套对象全都在，零序列化损失}不走 URL 编码，不担心类型丢失，Date 对象和深层嵌套结构都原样传递。唯一的心理负担是多了一个全局单例——我承认这不太"纯函数式"，但实用主义角度来说，比为了一个传参功能引入完整状态管理库划算太多了。还有一种场景值得一提：你打开新页面之后，希望新页面能往回传数据。比如说商品编辑页改完数据，返回列表页时列表页需要自动刷新。这种"双向通信"需求，用 JSON 序列化和 store 桥都别扭，但 uni-app 自带的事件通道机制刚好匹配：// 发送端（列表页打开编辑页时）uni.navigateTo({url: '/pages/edit/edit?id=789',events: {// 编辑页可以通过 getOpenerEventChannel() 拿到 channel 后 emit 这个事件fetchFullData: (sendBack: (data: any) => void) => {sendBack(fullDataSet); // 直接传完整对象，不走 URL 编码}}});// 接收端（编辑页的 onLoad 里）const channel = this.getOpenerEventChannel();channel.emit('fetchFullData', (data: any) => {this.editForm = data;});事件通道里的数据完全不走序列化，sendBack 传什么对方就拿到什么，没有类型转换的中间损耗。唯一限制是只有 navigateTo 打开的页面之间能用，redirectTo 和 switchTab 不支持。三种方案我都在实际项目里跑过，不存在哪个"最好"。量小用 JSON 序列化，量大用 store 桥，需要双向通信用事件通道，按场景选就完了。这摊事说白了就是一个教训：跨端开发的时候，千万别假设每个平台的参数传递机制都一样。你在微信小程序里写习惯了的传参方式，到了鸿蒙端可能静默翻车——而翻车的瞬间往往是你最忙、最没时间 debug 的时候。花一个小时翻源码搞清楚底层原理，比在生产环境 bug 上报了再手忙脚乱划算一百倍。老三，10 年+软件开发经验，软件设计师、人工智能应用工程师。平时鼓捣鸿蒙 ArkTS 北向开发和 Web 前端，也在折腾 AI 自动化。做的 App 叫雷达鸭——一个收录一人公司赚钱案例的工具，鸿蒙版在华为应用市场能搜到，微信小程序也同步上线。上面聊的 store 桥方案，就是雷达鸭商品详情页从列表页拿数据时跑的那一套。
