uni-app 鸿蒙端传参变成 [object Object]？顺着源码追到 ArkTS router 底层才搞明白

上个月同事跑过来问了我一个问题“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 在鸿蒙端的实现简化但保留了关键逻辑importrouterfromohos.router;interfaceNavigateToOptions{url:string;events?:Recordstring,(...args:any[])void;success?:(res:any)void;fail?:(err:any)void;complete?:()void;}exportfunctionnavigateTo(options:NavigateToOptions):void{// 第一步从 url 中拆出页面路径和查询字符串constquestionMarkIndexoptions.url.indexOf(?);constpathquestionMarkIndex-1?options.url.substring(0,questionMarkIndex):options.url;// 第二步把查询字符串解析成 params 对象constparams:Recordstring,string{};if(questionMarkIndex-1){constqueryStringoptions.url.substring(questionMarkIndex1);queryString.split().forEach((pair){consteqIndexpair.indexOf();if(eqIndex-1){constkeydecodeURIComponent(pair.substring(0,eqIndex));constvaluedecodeURIComponent(pair.substring(eqIndex1));params[key]value;// ← 注意value 始终是 string}});}// 第三步调 ArkTS 原生路由router.pushUrl({url:path,params:params// 类型签名params?: Recordstring, string}).then((){options.success?.({errMsg:navigateTo:ok});}).catch((err:Error){options.fail?.({errMsg:navigateTo:fail err.message});});}追到这里其实就已经看到线索了——params的类型是Recordstring, string。也就是说不管你传的是数字、布尔值还是对象经过 URL 的查询字符串这一层之后全变成了字符串。但问题是如果调用方确实做了JSON.stringify那到了接收端decodeURIComponent之后拿到的应该是一个 JSON 字符串才对JSON.parse不应该失败。既然框架层的逻辑没问题那锅只能往底层甩了。继续往下追。追到 ArkTS 的 router.pushUrl打开 HarmonyOS SDK 的ohos.router类型声明文件router.pushUrl的签名是这样的// ohos.router.d.ts — ArkTS 路由模块类型声明简化declarenamespacerouter{interfaceRouterOptions{url:string;params?:Recordstring,string;// ← 看清楚value 必须是 string}functionpushUrl(options:RouterOptions):Promisevoid;functionreplaceUrl(options:RouterOptions):Promisevoid;functionback(options?:{url?:string;params?:Recordstring,string}):Promisevoid;functiongetParams():Recordstring,string;// ← 取回来也是全 string}看到Recordstring, string这几个字的时候我脑子里像过电一样——突然理解为什么同事的代码会炸了。不是因为JSON.stringify没生效而是他写的代码路径根本就没走到JSON.stringify那一步。问题不出在 URL 编码/解码这个环节——那个逻辑是对的。问题出在一个更隐蔽的地方有些同学在拼 URL 的时候图省事直接用了拼接或模板字符串插值。JS 引擎碰到对象做字符串拼接会静默调用toString()结果就是你在开发者工具里看到的[object Object]。像这样// ❌ 这样写JS 引擎会隐式调用 obj.toString()constproduct{id:123,name:蓝牙耳机,price:199};uni.navigateTo({url:/pages/detail/detail?dataproduct// → ?data[object Object]});或者更隐蔽的写法——数据是通过变量传进来的调用的地方以为是字符串其实是对象// ❌ 接收了一个对象没注意到类型constqueryDataroute.query.data;// 这里实际是对象uni.navigateTo({url:/pages/detail/detail?info${queryData}// → ?info[object Object]});一眼看上去代码没错对吧因为模板字符串的${}插值会自动调用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接收端对称地解回来// 发送端constorderDetail{id:456,items:[A,B],total:398};uni.navigateTo({url:/pages/order/order?payload${encodeURIComponent(JSON.stringify(orderDetail))}});// 接收端onLoad(options:any){if(options.payload){constorderJSON.parse(decodeURIComponent(options.payload))asOrderDetail;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 行classPageBridge{privatecachenewMapstring,any();put(key:string,data:any){this.cache.set(key,data);}take(key:string):any{constdatathis.cache.get(key);this.cache.delete(key);// 取完即删防止内存积压returndata;}}exportconstpageBridgenewPageBridge();// 发送端pageBridge.put(currentOrder,orderDetail);uni.navigateTo({url:/pages/order/order?id456});// 接收端onLoad(options:any){constorderpageBridge.take(currentOrder)asOrderDetail;// order 是原始对象引用Date、嵌套对象全都在零序列化损失}不走 URL 编码不担心类型丢失Date对象和深层嵌套结构都原样传递。唯一的心理负担是多了一个全局单例——我承认这不太纯函数式但实用主义角度来说比为了一个传参功能引入完整状态管理库划算太多了。还有一种场景值得一提你打开新页面之后希望新页面能往回传数据。比如说商品编辑页改完数据返回列表页时列表页需要自动刷新。这种双向通信需求用 JSON 序列化和 store 桥都别扭但 uni-app 自带的事件通道机制刚好匹配// 发送端列表页打开编辑页时uni.navigateTo({url:/pages/edit/edit?id789,events:{// 编辑页可以通过 getOpenerEventChannel() 拿到 channel 后 emit 这个事件fetchFullData:(sendBack:(data:any)void){sendBack(fullDataSet);// 直接传完整对象不走 URL 编码}}});// 接收端编辑页的 onLoad 里constchannelthis.getOpenerEventChannel();channel.emit(fetchFullData,(data:any){this.editFormdata;});事件通道里的数据完全不走序列化sendBack传什么对方就拿到什么没有类型转换的中间损耗。唯一限制是只有navigateTo打开的页面之间能用redirectTo和switchTab不支持。三种方案我都在实际项目里跑过不存在哪个最好。量小用 JSON 序列化量大用 store 桥需要双向通信用事件通道按场景选就完了。这摊事说白了就是一个教训跨端开发的时候千万别假设每个平台的参数传递机制都一样。你在微信小程序里写习惯了的传参方式到了鸿蒙端可能静默翻车——而翻车的瞬间往往是你最忙、最没时间 debug 的时候。花一个小时翻源码搞清楚底层原理比在生产环境 bug 上报了再手忙脚乱划算一百倍。老三10 年软件开发经验软件设计师、人工智能应用工程师。平时鼓捣鸿蒙 ArkTS 北向开发和 Web 前端也在折腾 AI 自动化。做的 App 叫雷达鸭——一个收录一人公司赚钱案例的工具鸿蒙版在华为应用市场能搜到微信小程序也同步上线。上面聊的 store 桥方案就是雷达鸭商品详情页从列表页拿数据时跑的那一套。本文遵循 MIT 协议转载请注明出处。