微信公众号自定义菜单在配置跳转小程序时，仅支持填写小程序的页面路径以及不超过一定长度的URL query参数。当业务需要把筛选条件、用户轨迹、订单草稿等复杂对象传给目标页面时，单纯依靠菜单配置显然不够。借助小程序端的全局状态管理，将复杂参数在跳转前写入内存或本地缓存，再由落地页读取，是一条被验证可行的路径。
公众号菜单的参数限制与全局状态管理的切入点
在微信公众平台后台，自定义菜单的类型选为“跳转小程序”后，只能填写pagepath，例如pages/index/index，并可附带类似?id=123&type=2的查询字符串。这种机制本质上是一次HTTP风格的导航，参数必须序列化为键值对，且总长度受微信侧限制。对于嵌套JSON、数组、二进制编码等数据，直接拼在路径里既不可读也容易超限。
全局状态管理的核心思路是：把复杂参数从“导航参数”变成“环境上下文”。开发者可以在用户点击菜单前（比如通过服务端下发、或通过其他交互入口）将对象存入小程序的globalData或基于Storage的持久层；当小程序被菜单拉起并定位到目标页面时，页面的onLoad生命周期直接从全局容器取值。由于菜单仅承担“拉起小程序并去某个页面”的薄跳转职责，复杂数据走的是另一条通道，因此规避了配置层面的约束。
这种方案并不违反微信规则，因为菜单本身没有传递敏感或超量数据，只是触发了小程序的正常启动。需要注意的是，全局状态应被视为“一次性信使”，而非长期存储，否则在多场景入口叠加时会出现数据污染。后续小节会具体说明如何设计读写边界。
基于globalData与Storage的两种实现方式
最轻量的做法是利用小程序App实例上的globalData。在app.js中声明一个字段，比如menuPayload，在合适的时机（例如通过服务端接口获取菜单态数据后）赋值。目标页面通过getApp().globalData.menuPayload读取即可。下面是一个简单的写入与读取示例：
// app.js
App({
globalData: {
menuPayload: null
}
});
// 在某个数据准备逻辑中
const app = getApp();
app.globalData.menuPayload = {
filter: { city: 'shanghai', priceRange: [100, 500] },
cart: [{ sku: 'A1', qty: 2 }]
};
// 目标页面 pages/target/target.js
Page({
onLoad: function () {
const app = getApp();
const data = app.globalData.menuPayload;
if (data) {
console.log('收到菜单复杂参数', data);
this.processData(data);
// 读取后清空，防止下次误用
app.globalData.menuPayload = null;
}
},
processData: function (d) {
// 业务处理
}
});
不过globalData是纯内存对象，如果小程序进程被系统回收后再由菜单拉起，之前写入的数据会丢失。此时应改用wx.setStorageSync做持久化。将复杂参数JSON.stringify后存入本地缓存，目标页wx.getStorageSync取出并解析。该方式在冷启动后依然有效，但要注意清理，否则缓存会越积越多。
除了自带能力，也可引入第三方状态管理库（如基于Proxy的轻量store），统一封装“写菜单参数”和“消费菜单参数”的动作。其优势在于可加入过期时间、命名空间隔离等策略。下面的代码展示了一个带过期时间的Storage封装：
// store.js
function writeMenuPayload(obj, ttl = 5 * 60 * 1000) {
const packet = {
value: obj,
expire: Date.now() + ttl
};
wx.setStorageSync('menu_payload', JSON.stringify(packet));
}
function readMenuPayload() {
const raw = wx.getStorageSync('menu_payload');
if (!raw) return null;
const packet = JSON.parse(raw);
if (Date.now() > packet.expire) {
wx.removeStorageSync('menu_payload');
return null;
}
wx.removeStorageSync('menu_payload');
return packet.value;
}
module.exports = { writeMenuPayload, readMenuPayload };
对比来看，globalData适合参数生命周期短、用户操作连续的场景；Storage适合可能被系统杀死后重启的场景。两者都要求开发者主动清理，否则会出现“上一次菜单的数据跑到这一次页面里”的诡异bug。在实践中，建议以Storage为主、globalData为辅，并在统一入口做读取和销毁。
复杂参数传递中的常见误区与排查思路
第一个误区是认为菜单的query可以无限扩充。有开发者尝试把整个表单对象用encodeURIComponent压缩后塞进pagepath，结果在部分安卓机上菜单直接无法点击。微信对菜单配置有静默校验，超长或含特殊字符的路径会被服务端拒绝。全局状态管理才是正道，菜单只配最小可用路径，比如pages/target/target即可。
第二个误区是忽略多入口覆盖。小程序除了菜单，还可能被扫码、分享卡片、模板消息拉起。如果所有入口都往同一个menuPayload写数据，而目标页只认这个名字，就会造成参数互相覆盖。解决方法是按来源加前缀，例如menu_payload、scan_payload，或在对象里标记from字段，页面按来源分支处理。
第三个误区是敏感数据明文缓存。曾有团队把用户手机号、token写进Storage，结果被其他具备Storage读权限的脚本拿到。复杂参数若含隐私，应在服务端短期票据化：菜单只带一个ticket参数，落地页用ticket换真实数据。全局状态里只放ticket，不放明文，安全性更高。下面示例展示ticket换数据的流程：
// 菜单配置 pagepath: pages/target/target?ticket=abc123
Page({
onLoad: function (query) {
const ticket = query.ticket;
if (!ticket) return;
wx.request({
url: 'https://ipipp.com/api/menu/data',
data: { ticket: ticket },
success: (res) => {
// 此处拿到复杂参数，仅存于内存
this.setData({ list: res.data.list });
}
});
}
});
最后要提防“清不清空”的边界。如果在onLoad里读完全局状态却忘记置空，用户手动退出再点菜单，可能读到旧数据。建议在读取成功后的同步逻辑里立即销毁，并将异常分支（如解析失败）也纳入清理范围。只要把全局状态当成“一次性信封”，复杂参数传递就会变得稳定可控。