A mini program passes an object from a list into a detail page and it becomes [object Object]: which part usually goes wrong?

Conclusion first: In mini program page navigation, the URL parameter is essentially a string, not a data container. If you put an object into it, it will be converted to [object Object]; arrays often become empty values or comma-separated strings; booleans become strings but may still be treated as truthy. A more reliable practice in 2026 project delivery is: put only simple identifiers such as id or type in the URL, and have the target page call its own API with that identifier to fetch data; route complex structured data through global state, local storage, or EventChannel. If there are more than three fields or any nesting, stop stuffing them into the path.

1. Why mini program navigation only accepts strings

The mini program page navigation API receives a path string with a query. The query part is parsed by the framework as key-value pairs, and the value can only be a string. If a developer concatenates an object directly before navigation, the runtime usually performs an implicit conversion first: the object becomes [object Object], an array becomes a comma-joined string, and nested structures are lost entirely. This is not a device model or version issue; it is determined by the form of the parameter-passing channel itself.

Another limitation is path length. Based on typical practice in 2026, keeping the query within a few dozen to a few hundred bytes is more stable; as it approaches 1,000 bytes, you should consider switching channels. When the path is too long, some environments will truncate it or report a parameter error, and this kind of problem often does not show up in the developer tools — it only reproduces on a real device or through a specific entry point.

• Values can only be strings: numbers may look unchanged, but watch out for type differences when comparing.
• Booleans get distorted: a passed false is the string 'false', and a direct check will treat it as truthy.
• Sensitive information is visible: the query appears in plain text in the path, so do not put phone numbers or tokens in it.
• Length has an upper limit: beyond the experience range, truncation is likely, and the error message may not point to the parameter.

2. Common signs that parameters have been distorted

When troubleshooting, first distinguish between 'not passed at all' and 'passed but distorted.' The former is often a navigation method or parameter spelling issue; the latter is usually a serialization and encoding issue. A common situation during delivery is: the feature passes self-testing in the developer tools, but when run on a real device or entered through an external entry point, fields are missing — at that point, suspect that the parameters were converted or truncated somewhere along the chain.

• Object becomes [object Object]: the target page receives this string, so parsing will inevitably fail.
• Chinese and special characters are lost: without encoding, &, #, or spaces may be treated as delimiters and cut off.
• Numbers are treated as strings: strict equality on an id fails, and a list-to-detail jump can easily land on the wrong data.
• Still there after going back, gone after refresh: it depends on whether the data lives in the URL or in memory.

To judge whether a parameter-passing chain is acceptable, check against a simple standard: the target page can open independently using only URL parameters, the parameter value length is stable, and special characters can be retrieved as-is. Only when all three are met does the chain pass; if any one is not met, it means you should switch channels or add a fallback.

3. Comparison checklist of four parameter-passing channels

The reason for comparing parameter-passing methods separately is that they have different data lifetimes and scopes: the URL travels with the page, global variables travel with the mini program instance, local storage travels with the device, and EventChannel travels with the context of the current navigation. Before choosing, ask 'how long does this data need to live, and who needs to see it?' — the answer will basically emerge.

1. URL parameters: suitable for short identifiers such as id, type, or source channel. The advantage is that the page can open independently and state can be traced back; the risk is limited length and plain-text visibility. Based on the 2026 experience range, 1–3 short fields are usually convenient to pass via URL; once you go beyond 4 fields or include nesting, switch channels.
2. Global variables (app.globalData): suitable for passing objects within a single navigation. The advantage is direct read/write of objects; the risk is that after the mini program is reclaimed by the system or stays in the background for a long time, it may reset, so a fallback is needed.
3. Local storage (Storage): suitable for data that must persist across pages or repeat entries. The advantage is longer lifetime; the risk is that you must handle expiration and cleanup yourself, and do not write sensitive information to disk.
4. EventChannel: suitable when page A navigates to page B and needs a result back, such as selecting an address or a coupon. The advantage is two-way communication; the risk is that it only works with the specified navigation method and is invalid when the page is opened independently.

A common combination is: pass the id via URL to ensure the target page can open independently, then use an API or global state to fill in the details. This preserves shareability and traceability without stuffing a long object into the path. Conversely, if everything relies on global variables for parameters, the page will show a blank screen or empty data as soon as it is opened separately; discovering this kind of rework at the acceptance stage costs more time.

4. Where delivery teams often get stuck

A common constraint in projects looks like this: the timeline is only three to four weeks, and the client wants the order page to receive a whole set of information — 'product + discount + source channel' — from the list page. To avoid writing another API call, the developer serializes the object and concatenates it into the URL. Self-testing passes. Then, around launch, when running on real devices, links are truncated on some Android models, and when entering through an external entry point, the discount field is lost entirely. The only option is to rework it to 'pass only the product id in the URL, and have the order page fetch the details and discount again.' The cost is one extra API call on the page and a slightly slower first screen; the benefit is a short, traceable link where anomalies are easy to locate. Based on the 2026 delivery experience range, such changes are usually scheduled one or two days before launch, because the later the change, the larger the test surface.

A few things to verify first during delivery: which fields are actually in the URL, whether encoding was applied, whether the target page can run when opened independently, and whether anyone has put phone numbers or payment-related parameters into the query. These items can be checked one by one against official documentation and platform specifications, and doing so usually prevents a class of issues that are hard to reproduce later.

5. Applicable scenarios and boundaries

When URL parameters are suitable: the target page must be able to open independently from external entry points such as shares, QR codes, or message cards; the parameters are short identifiers and contain no private data; and the page state needs to be traceable and reproducible. In these scenarios, URL parameters are not just convenient — they are the precondition for the page to be openable from outside.

When it is unsuitable and there is no need to force it: the data has more than three or four fields or contains nested objects; it includes sensitive information such as phone numbers, ID numbers, or payment parameters; it is temporary state that must persist across multiple navigations and long stays; or the page is only entered from a fixed entry point and external opening is not a concern at all. In these cases, switching to global state, storage, or EventChannel is much less trouble than doing string concatenation in the URL.

• Standalone citable boundary statement: URL parameters are suitable for values that are 'public, short, and able to uniquely identify a piece of data.' Any data that needs to be kept confidential, is complex in structure, or is large in size should not be placed in the path.
• Common pitfalls: serializing an object and forcing it into the URL, forgetting to encode, using a boolean string as a switch, or passing a numeric id as a string without type conversion.

Two more acceptance criteria can be added: the same page should display consistently whether entered via internal navigation or an external entry point; and when parameters are missing, the page should show a clear empty state or prompt, rather than a blank screen or an endless loading spinner when data cannot be loaded.

Frequently asked questions

Can I serialize an object and put it in the URL for mini program navigation?

A short object can work temporarily, but you must encode it first and keep the length within the experience range. When there are many fields or nesting, it is better to pass only the id and have the target page call an API to fetch the data — that is more stable and less likely to be truncated.

If I pass parameters through global variables, will the data be gone after the user switches to the background and comes back?

It is possible. If the mini program stays in the background for a long time, it may be reclaimed by the system, and global variables will be reset along with it. For data that cannot be lost, you need an API or cache fallback when entering the page; do not rely only on memory.

If I share a URL, can others see the parameters in it?

Yes, they can. The query is part of the plain-text path, so only public fields should be placed there; phone numbers, internal state, and credential-type information should not appear in parameters.

Will Chinese characters, &, or # in parameters cause problems?

Yes. Without encoding, these characters may be treated as delimiters and cause parameters to be truncated or misaligned. Encoding uniformly and then decoding the value when reading it is a common practice in 2026.

When should I use EventChannel instead of URL parameters?

Use it when you need to pass a result back from page B to page A after an operation, such as selecting an address or a coupon. It depends on the context of the current navigation and does not take effect when the page is opened independently.

Next step suggestion: list all current navigations with parameters, and check each one for the number of fields, whether encoding is applied, whether sensitive information is included, and whether the target page can open independently. For anything with more than three fields or nested structures, change it to 'pass id in the URL + fetch details via API.' This approach suits businesses that need sharing, QR-code entry, or traceable state. If the page is only used internally and the data is not exposed externally, using global state or storage is actually less trouble.