2026年了，Uni-app 两个页面联调，一个说传了对象，一个说收到字符串，该信谁？

Uni-app 页面跳转时传了一个对象，接收页 onLoad 里拿到的却是字符串，这通常不是框架坏了，而是 URL 传参机制本身只承载字符串。uni.navigateTo、uni.redirectTo 等 API 会把参数拼在路径 query 上，非字符串值通常会被序列化，接收端需要按约定反序列化，否则就会得到「看起来像对象、实际是字符串」的值。2026 年多端交付里，这个问题在 H5、小程序和 App 端表现略有差异，但根因一致。

URL 传参到底把对象怎么了

在 Uni-app 跨端开发里，页面跳转传参常见的方式是拼 URL。小程序端、App 端和 H5 端最终都会把参数转成路径字符串，区别只在序列化细节。对象、数组这类引用类型不会原样传递，有的端会隐式调用 toString 得到 [object Object]，有的端会保留 JSON 形态但仍是字符串。因此接收页先看到的是字符串，再想当对象用，需要自己 JSON.parse。

判断方法很直接：在目标页 onLoad 里打印 typeof options.xxx 和原始值，不要凭肉眼猜。如果传的是简单 id、状态标记，直接使用即可；如果传的是对象，就要在发送前显式 JSON.stringify，接收后显式 JSON.parse，并且用 try/catch 包住解析，避免异常参数导致页面白屏。

• 核心结论：URL query 只认字符串，对象通常会被序列化，接收端要负责反序列化。
• 多端差异：不同平台对特殊字符、长度限制、编码方式处理不完全一样，不要依赖隐式转换。
• 验收口径：目标页拿到的类型和发送前一致，缺失参数有兜底，解析失败不白屏。

哪些参数适合走 URL，哪些别硬塞

URL 传参的优点是直观、可分享、可回退，适合传简单、非敏感、体量小的数据。比如列表页跳到详情页传一个商品 id，或者从活动页跳到表单页传一个来源标记。这些场景只传一个或几个短字段，各端表现稳定，调试也简单。2026 年常见做法是把 URL 传参当成「页面身份证」，而不是「数据搬运车」。

反过来，把完整对象、长文本、图片 base64、用户令牌这类内容塞进 URL，就容易踩坑。小程序端和部分 App 容器对 URL 长度有经验区间限制，常见区间是超过一两千字符就可能被截断或触发平台差异；H5 端链接过长也不利于分享和埋点。更稳妥的做法是只传标识，接收页按标识重新请求或从缓存读取。

• 适合：id、类型标记、来源渠道、简单筛选条件、短状态码。
• 不适合：大对象、敏感信息、二进制、需要跨刷新保留的数据。
• 边界：如果发现要传的字段超过三五个，或者字段值本身超过几十个字符，优先考虑换传参方式。

传参方式怎么定——一个「四问」判断顺序

与其每次都纠结用哪种方式，不如固定一套判断顺序。下面这个「传参四问」来自项目交付时的约定，按顺序问完，基本能定下方案。它的价值在于把「能不能传」变成「该不该传」，减少联调时互相甩锅。

1. 问数据量：只有 id 或几个短字段？走 URL。字段多或值长，进入下一问。
2. 问生命周期：只在当前跳转链路里用，返回就丢？可以用全局状态或事件总线。需要跨刷新、跨启动保留？用本地存储。
3. 问实时性：接收页要立刻反映发送页的最新值？用全局状态或状态管理，避免 URL 快照过时。
4. 问敏感性：是否包含令牌、手机号、内部状态？不要放 URL，改走接口按 id 重新取，或放内存并在离开时清理。

每步的注意点不同：URL 要注意编码和长度；全局状态要注意页面返回时是否重新读取；本地存储要注意键名规范和清理时机；接口重新拉取要注意 loading 和失败兜底。把这四问贴在项目规范里，新人也能按同一口径选择。

交付现场：一次因为传参方式返工的联调

在项目里常见的情况是：周期紧、多端并行，前端同学为了省事，把筛选条件对象整个 JSON.stringify 后塞进 URL。开发环境一切正常，到了测试环境，H5 分享链接变长，小程序端偶尔截断，接收页解析失败后白屏。甲方卡在验收前三天报过来，团队只能回头改传参规范：简单筛选走 URL，复杂条件走全局状态加本地缓存，接收页统一做解析兜底。结果多花了一轮回归时间，但也把后续页面的传参口径固定下来。

按项目交付习惯，这类问题建议在联调前就约定好：哪些参数走 URL、哪些走状态、哪些必须重新请求。约定写在接口文档或前端规范里，比事后救火省事。约束条件是预算和周期都有限，做法是先用四问框架过一遍，代价是前期多花半小时对齐，收益是少一轮返工。常见经验区间是，前期对齐多花 0.5～1 小时，能减少一轮半天到一天的联调返工。

常见问题

uni.navigateTo 传对象，接收页 JSON.parse 报错怎么办？

先确认发送端有没有 encodeURIComponent，字符串里是否带未转义的特殊字符；接收端用 try/catch 包住 parse，失败时给默认值或回退列表页，不要直接白屏。

用全局状态传参，为什么返回上一页数据没更新？

全局状态存的是引用，但页面可能没重新读取。可以在 onShow 里重新取一次，或让状态变更触发订阅；如果返回后界面还是旧值，先查生命周期里有没有刷新逻辑。

Uni-app 的 H5 端和微信小程序端传参行为一样吗？

基础机制都是 URL query，但编码、长度限制和路由表现有差异。常见做法是发送端统一显式序列化，接收端统一显式反序列化，不要依赖某个端的隐式转换。

参数里有中文或特殊符号，传过去变乱码了怎么办？

发送前用 encodeURIComponent 编码，接收后 decodeURIComponent 解码。如果链接还要分享到外部，建议只传 id，中文内容由接收页按 id 重新请求。

传大对象用 URL 还是本地缓存？怎么选？

大对象不建议走 URL。若只在当前会话用，放全局状态；若需要跨页面或刷新保留，放本地缓存，并约定键名和清理时机，避免脏数据残留。

行动指引：下次页面跳转前，先用「传参四问」判断数据量、生命周期、实时性和敏感性，再决定用 URL、全局状态还是本地缓存。适用边界：简单短字段、非敏感数据适合 URL；大对象、敏感信息、需要跨刷新保留的数据，走状态或存储更稳。2026 年多端交付里，把传参规范写进前端约定，比事后排查省时间。