企业官网建设流程全解析

控制台里冒出switchTab:fail can not switch to no-tabBar page这行红字的时候，十有八九不是代码写崩了，而是你把一次页面跳转的"通道"选错了。这个报错在小程序开发里出现的频率极高，尤其是版本迭代把某个页面从底部导航里摘掉、或者新同学照着旧代码抄跳转逻辑的时候，一测就炸。它的字面意思很直白：你调用了switchTab这个专门用来切换底部 tabBar 页面的接口，但传入的目标路径并不在 tabBar 的声明列表里，框架在跳转前的校验阶段就直接把这次调用拦了下来，页面自然纹丝不动。

很多新手第一反应是"路径写错了"，然后反复检查拼写，结果发现路径完全正确——问题在于这个接口的能力边界和页面身份不匹配。switchTab从设计之初就只服务于底部导航栏上的那几个页面，它能做的事很单一：关掉所有非 tabBar 页面，把目标 tabBar 页面激活。你把一个普通页面塞给它，它只能报错。反过来，navigateTo和redirectTo遇到 tabBar 页面也会报类似的错，只是 errMsg 换了措辞，这些坑本质上是一套的。

这篇内容适合三类人：刚接触小程序页面路由、被这个报错卡住的新手；正在做页面架构调整、要把某些页面加进或移出底部导航的开发者；以及想给自己项目定一套"跳转规范"、避免团队反复踩坑的负责人。我会把这个报错的成因、判断方法、五种典型场景的正确写法、参数传递的绕路方案，还有排查顺序和一堆只有踩过才知道的细节全部摊开讲，代码都能直接抄进项目里跑。

1. 把报错拆开看：switchTab 与 no-tabBar page 到底在互相否定什么

1.1 一行 errMsg 里的两个关键词

先逐字读一遍这行错误：switchTab:fail can not switch to no-tabBar page。冒号前面是接口名switchTab，冒号后面是fail回调里拿到的errMsg。整句话翻译成人话就是"这个接口调用失败了，因为它没法切换到一个不是 tabBar 的页面"。注意这里的主语是"接口"，不是"页面"——页面本身完全正常，能通过navigateTo打开，只是switchTab这个入口不认它。

no-tabBar page是框架内部对页面身份的一种归类。在一个小程序里，所有页面被粗暴地分成两类：一类在app.json的tabBar.list里登记过，叫 tabBar 页面；剩下的统统是非 tabBar 页面。这个身份是静态的、编译期就确定的，运行时改不了。所以你在业务代码里用if判断"这个页面算不算 tabBar 页面"，本质上是在猜框架的配置表，猜错了就报这个错。

fail回调是个很关键的信息源。不少同学写switchTab的时候只写success，出错时控制台一片安静，只能靠肉眼找问题。养成习惯，凡是跳转类接口都把fail打出来，errMsg里通常已经把原因写得很清楚了，比盲猜快十倍。

1.2 四个页面跳转接口的分工边界

小程序的路由接口就那几个，但每个的能力范围差别很大，混用就是灾难。我整理了一张表，建议直接贴在项目文档里：

这张表里有两个信息很容易被忽略。第一，switchTab不支持 query，你拼了?id=123也不会报错，但目标页的onLoad(options)里拿到的options是空的，参数凭空消失，这种"不报错但没数据"的问题比直接报错更难查。第二，reLaunch是唯一一个"通吃"的接口，既能跳 tabBar 页也能跳普通页，还能带参数，代价是它会清空整个页面栈，用户按返回键直接退出小程序。

选择接口的逻辑其实很简单：先问目标页是不是 tabBar 页，是就走switchTab或reLaunch；不是就在navigateTo和redirectTo里选，看你要不要保留当前页面。问题在于，很多项目的跳转路径是动态拼接的、或者从配置接口下发的，代码在写的时候根本不知道目标页是哪种身份，这时候就需要一层封装来判断，后面第 4 节会给出具体的工具函数。

1.3 框架在跳转前做了哪些校验

理解校验顺序，排查才能有序。框架在一次跳转请求里大致会检查这么几件事：路径是否在小程序已注册的页面列表里、目标页的页面类型（tabBar / 非 tabBar）与接口是否匹配、页面栈是否超过上限、当前是否有正在进行的路由动画。

switchTab:fail can not switch to no-tabBar page这条错误说明前两步已经过了——路径确实存在，否则报的会是另一个错误，比如找不到页面。也就是说，你的路径拼写大概率是对的，只是这个页面没在tabBar.list里。这个判断很重要，能帮你省掉大量"检查拼写"的时间，直接去翻配置文件。

还有一种相近但不同的情况：路径本身写错了，指向一个不存在的页面。这时候不同版本的容器给出的errMsg措辞不太一样，有的会说页面不存在，有的会静默失败。所以排查时不要只盯着这一条报错，把fail里的原始errMsg完整打印出来，对照着看。

提示：不同小程序容器的 API 前缀不同（有的用wx.，有的用my.，跨端框架里是uni.），但跳转接口的语义、限制和报错逻辑基本一致，本文的结论可以平移到各个平台。

2. 从 app.json 出发：tabBar 声明的三种状态与判断方法

2.1 tabBar.list 的 pagePath 与接口 url 的写法差异

这是导致这个报错的头号元凶，而且极其隐蔽。看下面两段配置：

{ "pages": [ "pages/index/index", "pages/category/category", "pages/cart/cart", "pages/mine/mine" ], "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/category/category", "text": "分类" }, { "pagePath": "pages/cart/cart", "text": "购物车" }, { "pagePath": "pages/mine/mine", "text": "我的" } ] } }

// 跳转时的写法 wx.switchTab({ url: '/pages/index/index' })

看出来了吗？tabBar.list[].pagePath是不带前导斜杠的相对路径，而switchTab的url是带前导斜杠的绝对路径。这两套写法在框架内部会被归一化处理，正常情况不会出问题。但如果你在代码里写了自己的白名单来判断"这个页面是不是 tab"，两边格式没统一，就会出现"配置里明明有、代码里判断成没有"的诡异现象。

更麻烦的情况是动态拼接。比如从接口拿到一个页面标识index，代码里拼成'/pages/' + name + '/' + name，结果接口返回的是pages/index/index（带 pages 前缀），拼出来就变成了/pages/pages/index/index/index。这种错误在switchTab上表现为找不到页面，在别的接口上表现更隐蔽。我的做法是：所有页面路径在代码里统一用带前导斜杠的绝对路径，配置读取时做一次归一化转换，绝不在业务层手拼字符串。

2.2 自定义 tabBar 下的隐藏陷阱

从某个基础库版本开始，小程序支持自定义 tabBar：在app.json的tabBar里加"custom": true，然后自己写一个组件渲染底部导航。这个能力很香，可以做出各种花哨的动画和角标效果，但它带来了一个高频误解——很多同学以为开了自定义之后，页面就不需要在list里声明了。

事实恰恰相反。自定义 tabBar 只是把"长什么样"交给你，但"哪些页面算 tabBar 页面"这个身份认定依然由tabBar.list决定。你把list清空或者删掉某项，那个页面立刻变成普通页面，switchTab一调就报can not switch to no-tabBar page。我见过一个项目组排查了整整一个下午，最后发现是重构时把list简化成了只有两个条目，另外两个页面还挂在自定义组件里当按钮用。

自定义模式下还有个连带的坑：切换 tab 时选中态不会自动更新。因为底部导航是你自己渲染的，框架不管高亮，你需要在每个 tabBar 页面的onShow里主动去更新组件实例的选中项。常见做法是给自定义 tabBar 组件挂一个getTabBar之类的取值方法，页面onShow时调用它设置selected索引。这块如果漏了，表现就是"页面切过去了，但底部高亮还停在原来那个"，用户会以为点击没生效。

2.3 分包、主包与路径大小写

第三个高频原因藏在工程结构里。tabBar 页面必须声明在主包中，这是一条硬约束。如果你为了减包把某个页面挪进了分包，同时它又还在tabBar.list里，构建阶段或者运行阶段就会出问题。反过来也成立：一个原本在主包里的 tabBar 页面被挪进分包后，list里那条配置必须同步删掉，代码里所有switchTab对这个页面的调用也要改成navigateTo或reLaunch。

路径大小写是另一个阴间问题。不同操作系统对文件名的处理不一样，本地开发时把pages/Order/order写成pages/order/order可能照样能跑，但打包到某些环境就找不到页面了。switchTab在这种情况下报的错未必是这一条，可能变成找不到页面，但排查方向是一样的：把配置里的路径和实际目录结构一个字符一个字符地对一遍，尤其注意目录名、文件名的大小写和扩展名。

注意：路径比对时不要只看 IDE 的自动补全结果，自动补全会"帮你修正"大小写，看起来对了，实际配置文件里还是错的。直接打开app.json和目录树手动对。

3. 五类真实场景的正确写法与代码

3.1 普通页跳 tabBar 页：最标准也最容易写错

这是最基础的场景，也是最容易出问题的地方。比如在商品详情页点"回首页"，正确写法是：

// ✅ 正确：目标页在 tabBar.list 中 wx.switchTab({ url: '/pages/index/index', success() { console.log('切换成功') }, fail(err) { console.error('切换失败', err.errMsg) } })

错误的写法通常长这样：

// ❌ 错误一：目标是普通页，却用了 switchTab wx.switchTab({ url: '/pages/detail/detail' }) // ❌ 错误二：拼了 query，参数会丢失（未必报错，但拿不到数据） wx.switchTab({ url: '/pages/index/index?id=1' }) // ❌ 错误三：路径没带前导斜杠，部分容器会解析异常 wx.switchTab({ url: 'pages/index/index' })

这里要专门说一下switchTab的行为特征：它会把所有非 tabBar 页面全部关闭，然后激活目标 tabBar 页。什么意思呢？用户从首页进入列表页，再从列表页进入详情页，此时页面栈里是三层；在详情页点"回首页"，switchTab执行后，列表页和详情页全部被销毁，页面栈只剩首页这一层。用户这时候按物理返回键，直接退出小程序，回不到刚才的详情页。这个体验是否符合产品预期，必须提前想清楚。

如果你的场景是"用户只是想去首页看看，看完还要回来"，那switchTab就是错的，应该考虑navigateTo到首页的某个副本页面，或者干脆用 tab 切换的交互替代。反之，如果场景是"流程结束，回首页重新开始"，switchTab或者reLaunch才是正解。

3.2 tabBar 页之间互跳：为什么不推荐 switchTab 互跳

底部导航本身就能切页面，理论上不需要代码里再调switchTab做 tab 之间的跳转。但实际业务里确实有这种需求，比如在"我的"页面点"去看购物车"，或者在空购物车页面点"去逛逛"跳到分类页。

技术上完全可行：

// 在 pages/mine/mine 页面里跳购物车 wx.switchTab({ url: '/pages/cart/cart', success() { // 自定义 tabBar 场景下，这里要同步更新底部高亮 const page = getCurrentPages().pop() if (typeof page.getTabBar === 'function' && page.getTabBar()) { page.getTabBar().setData({ selected: 2 }) } } })

但要留意一个体验问题：switchTab在 tabBar 页面之间跳转时，如果目标页面之前已经被加载过，它不会重新触发onLoad，只会触发onShow。很多人想在跳过去之后刷新购物车数据，写在onLoad里就完全不生效，还以为是接口挂了。正确的做法是把数据刷新逻辑放在onShow里，或者用标志位控制、避免每次onShow都发请求。

另外，在用了自定义 tabBar 的情况下，页面之间的switchTab必须手动同步选中态，否则会出现"页面跳了但底部高亮没变"的割裂感。这个细节在官方文档里只是一笔带过，实际项目里几乎人人踩过。

3.3 目标页被移出 tabBar 后的连带修改

这是这个报错最高发的触发场景，没有之一。产品迭代时决定把"购物车"从底部导航里拿掉，改成从"我的"页面进入。开发同学改了app.json，删掉了list里购物车那一项，页面本身还在，pages数组里也留着。看起来一切正常，直到有人点了那个"去购物车"的按钮——报错来了。

问题的根源是：switchTab的调用点散落在项目各处，改配置的人未必知道有哪些地方在调。这类改动必须做一次全量扫描，把目标页面的所有引用点找出来。我习惯用两步走：

第一步，全局搜索目标路径字符串，比如/pages/cart/cart，把所有出现的位置列出来，包括switchTab、navigateTo、redirectTo、reLaunch、navigator组件的open-type、以及各种营销位配置里的跳转链接。

第二步，逐个判断调用方式该怎么改。原来的switchTab要改成navigateTo（保留来源页）或redirectTo（不保留），原来用navigator组件且open-type="switchTab"的要改成open-type="navigate"。

最后一行是最容易翻车的。自定义 tabBar 组件里通常硬编码了selected索引和页面的对应关系，删掉一项之后，后面所有索引都要前移。如果只删了list配置没动组件，用户点"分类"可能跳到"我的"，这类问题测试时如果不逐项点一遍根本发现不了。

3.4 需要带参数跳 tabBar 页的三种替代路径

switchTab不支持 query，这是硬限制，绕不过去，只能换思路。常见的三条路：

第一条，换成reLaunch。reLaunch支持 query，跳转后目标页onLoad能拿到参数，代价是页面栈被彻底清空。适合"流程结束回首页并带上结果"这种场景，比如支付完成后回到首页并展示一个提示。用这个方案要注意，用户从首页按返回键会直接退出小程序，产品上要确认能接受。

第二条，用全局数据或本地缓存暂存参数。switchTab前把参数写到app.globalData或者Storage里，目标页onShow时读出来，读完清掉。这是最常用的方案，兼容性好，不改变页面栈行为。缺点是数据是"约定式"传递，如果目标页在别的地方也被打开，可能读到脏数据，所以用完必须清空。

第三条，用事件总线或状态管理。项目里如果已经引了全局状态管理，直接派发一个事件、目标页订阅即可。本质上和第二条是一回事，只是走得更规范。

// 方案二示例：跳转前暂存，目标页消费 // 来源页 wx.setStorageSync('__tabParams__', { from: 'detail', id: 123 }) wx.switchTab({ url: '/pages/index/index' }) // 目标页 pages/index/index 的 onShow onShow() { const params = wx.getStorageSync('__tabParams__') if (params) { wx.removeStorageSync('__tabParams__') // 关键：立即清空 this.handleIncomingParams(params) } }

这里有个我踩过的坑：清空动作一定要放在读取之后、处理逻辑之前，不要放在处理逻辑后面。因为处理逻辑里万一抛异常，缓存就残留了，下次进首页会莫名其妙地消费到上一次的旧参数，排查起来非常费劲。

3.5 从深层页面回首页：reLaunch 与 switchTab 的体验差异

这两种写法在"回首页"这个需求上都很常见，但体验完全不同，很多人是随手选一个。差别在这：

switchTab只关闭非 tabBar 页面，tabBar 页面之间的页面实例会被保留。也就是说，用户从首页进到分类页、再进到购物车页（两个都是 tabBar 页），在购物车页调switchTab回首页，分类页和购物车页的实例还在栈里，只是被挂起了，下次切回去状态还在、onLoad不会重新执行。

reLaunch则是关闭所有页面，包括 tabBar 页面，然后重新打开目标页。所有页面实例被销毁，目标页的onLoad会重新执行，生命周期从头开始。

选哪个取决于你要不要"重置状态"。如果回首页只是想展示，保留其他 tab 的浏览状态更好，用switchTab；如果回首页意味着"重新开始"，比如切换了城市、切换了账号，所有列表都要重新拉取，那就必须reLaunch，否则其他 tab 页还挂着旧城市的数据，用户切过去会看到错乱的内容。

// 切换城市后回首页，需要重置所有 tab 页状态 function backToHomeAfterCityChange() { wx.reLaunch({ url: '/pages/index/index', fail(err) { console.error('reLaunch 失败', err.errMsg) } }) }

4. 参数传递与跳转封装：把错误挡在业务代码之外

4.1 全局数据、本地缓存、事件总线三者的取舍

三种暂存方案不是随便挑的，各自的适用边界挺清晰：

我的默认选择是globalData加一个"一次性消费"的约定，简单直接。只有确实需要在小程序被杀掉重启后还保留的东西，才用Storage。事件总线我一般只在项目已有状态管理的前提下才用，为了一个参数专门引一套总线，维护成本不划算。

4.2 一个可复用的 tab 跳转工具函数

与其在每个调用点都判断一次，不如封一个统一入口。这个函数我在几个项目里都用过，基本能覆盖 90% 的跳转需求：

// utils/nav.js const TAB_PAGES = [ '/pages/index/index', '/pages/category/category', '/pages/cart/cart', '/pages/mine/mine' ] function normalize(url) { if (!url) return '' const path = url.split('?')[0] const withSlash = path.startsWith('/') ? path : '/' + path return withSlash.replace(/\/+$/, '') // 去掉尾部多余斜杠 } function isTabPage(url) { return TAB_PAGES.includes(normalize(url)) } function parseQuery(url) { const query = url.split('?')[1] if (!query) return null return query.split('&').reduce((acc, pair) => { const [k, v = ''] = pair.split('=') acc[decodeURIComponent(k)] = decodeURIComponent(v) return acc }, {}) } /** * 统一跳转入口 * @param {string} url 目标路径，可带 query * @param {object} options { replace: 是否替换当前页, params: 额外参数 } */ function nav(url, options = {}) { if (!url) return Promise.reject(new Error('url is required')) const target = normalize(url) const query = parseQuery(url) || {} if (isTabPage(target)) { // switchTab 不支持 query，参数走全局暂存 if (Object.keys(query).length || options.params) { const app = getApp() app.globalData = app.globalData || {} app.globalData.__pendingTabParams__ = Object.assign({}, query, options.params || {}) } return new Promise((resolve, reject) => { wx.switchTab({ url: target, success: resolve, fail: (err) => { console.error('[nav] switchTab 失败', target, err.errMsg) reject(err) } }) }) } const api = options.replace ? wx.redirectTo : wx.navigateTo return new Promise((resolve, reject) => { api({ url, success: resolve, fail: (err) => { console.error('[nav] 跳转失败', url, err.errMsg) reject(err) } }) }) } module.exports = { nav, isTabPage, normalize }

这个封装解决三个问题：一是调用方不用关心目标页的身份，传路径就行；二是 tab 页带参数时自动转存，不用每处都写一遍Storage；三是统一打日志，出错时能立刻定位是哪个页面调了哪个接口。

配套地，tabBar 页面的onShow里需要消费一次参数：

// pages/index/index.js Page({ onShow() { const app = getApp() const pending = app.globalData && app.globalData.__pendingTabParams__ if (pending) { app.globalData.__pendingTabParams__ = null // 先清空再处理 this.applyParams(pending) } this.refreshData() }, applyParams(params) { // 业务逻辑：比如切到指定城市、滚动到指定模块 if (params.city) { this.setData({ city: params.city }) } } })

4.3 数据刷新时机：onLoad 不触发怎么办

这是switchTab带来的第二个大坑，和报错无关但经常被一起讨论。因为switchTab不销毁已有的 tabBar 页面实例，目标页的onLoad只在第一次进入时执行，后续再切回来只走onShow。所以"每次进页面都要刷新"的需求，必须写在onShow里。

但把所有刷新都塞进onShow也有副作用：从二级页面返回时会触发、从后台切回前台时会触发，如果不做节流，接口会被打爆。我通常用一个时间戳做简单节流：

Page({ data: { list: [] }, onShow() { const now = Date.now() if (!this.__lastRefresh || now - this.__lastRefresh > 3000) { this.__lastRefresh = now this.fetchList() } }, fetchList() { // 拉数据 } })

三秒的阈值不是随便定的，大致对应"用户从详情页返回"的正常操作间隔。太短等于没节流，太长会显得数据陈旧。具体数值按业务调，列表类页面可以短一点，配置类页面长一点也无所谓。

5. 排查实录：从报错到定位的五分钟路径

5.1 逐层排查的顺序不要乱

遇到这个报错，别急着改代码，按下面的顺序走一遍，通常三分钟内能定位：

第一步，把fail里的errMsg完整打出来。确认报的确实是can not switch to no-tabBar page，而不是"页面不存在"之类的其他错误。这一步能排除掉一半的干扰。

第二步，打开app.json，看tabBar.list里到底有哪些pagePath。不要凭记忆，直接看文件。特别留意是不是最近有人改过这一块，比如把某项注释掉了、或者挪到了别的分支。

第三步，把报错时的url和list里的pagePath做归一化比对。去掉前导斜杠、去掉尾部斜杠、统一大小写，然后逐一对照。这一步能抓到绝大多数路径不一致的问题。

第四步，确认tabBar是否开了custom: true，如果开了，检查list是否还完整。自定义 tabBar 场景下漏配list是高频原因。

第五步，确认目标页面是否在主包内。如果最近做过分包改造，这一条的可能性极高。

第五步走完还没找到，就去全局搜索这个url字符串，看看是不是有配置文件、营销位或者服务端下发在调用switchTab，这些位置经常被忽略。

5.2 常见问题速查表

这张表建议放在项目 wiki 首页，"页面跳转报错"这一类问题，八成都在这张表里。

5.3 几个反直觉的坑

坑一：switchTab的success回调不代表页面渲染完成。它只代表跳转动作被接受了，页面的数据加载是异步的。如果你在success里立刻去getCurrentPages()取目标页实例做操作，拿到的可能是旧页面或者空对象。正确做法是通过全局状态或事件通知目标页自己去处理。

坑二：getCurrentPages()在 tabBar 页面之间的行为。用switchTab切 tab 时，虽然其他 tabBar 页面实例被保留，但getCurrentPages()返回的数组里只会包含当前激活的那个（加上可能的普通页面）。所以想通过页面栈去操作"另一个 tab 页"，是行不通的。

坑三：navigator组件的open-type默认值容易误导。不写open-type时默认是navigate，跳普通页没问题，但跳 tabBar 页会失败。有些同学以为navigator会智能判断，实际上它和接口一样死板，必须显式写open-type="switchTab"。

坑四：开发工具的路径校验比真机宽松。有些路径配置错误在开发者工具里能跑，真机上就报错，尤其是大小写和中文路径。遇到"真机才复现"的跳转问题，优先怀疑路径配置。

坑五：页面栈超过 10 层的报错会被误认成 tabBar 问题。navigateTo有层级上限，超过之后跳转会失败，errMsg里是另一套措辞。如果项目里跳转层数很深，排查时顺手确认一下getCurrentPages().length，别把两个问题搞混。

6. 跳转规范与上线前自检

6.1 把路由约定写进团队规范

这个报错之所以高频，本质原因是"页面身份"这个信息在代码里是隐式的——只有app.json知道谁是 tabBar 页，业务代码全靠约定。约定一旦没人维护，就会散架。

我的做法是把 tabBar 路径抽成一个常量文件，配置和代码都从这一份来源取，避免两处维护：

// constants/pages.js export const TAB_PAGES = { HOME: '/pages/index/index', CATEGORY: '/pages/category/category', CART: '/pages/cart/cart', MINE: '/pages/mine/mine' } export const TAB_INDEX = { [TAB_PAGES.HOME]: 0, [TAB_PAGES.CATEGORY]: 1, [TAB_PAGES.CART]: 2, [TAB_PAGES.MINE]: 3 }

配合前面的nav工具函数，业务代码里只写nav(TAB_PAGES.CART)，不做任何身份判断。以后页面加减 tab、调整顺序，只改这一个文件，不会漏。

另外建议在代码评审清单里加一条：任何新增的跳转调用，必须通过nav函数，不允许直接调wx.switchTab/wx.navigateTo。这条规矩能挡掉大部分低级错误，代价只是团队要适应几天。

6.2 上线前该手动验的几件事

自动化测试很难覆盖跳转体验，这几个点我每次发版前都会手动过一遍：

第一，从最深的页面往回按，看看每一层能不能正常返回，特别是那些用switchTab和reLaunch的入口，确认按返回键的行为符合预期（是回到上一页，还是直接退出）。

第二，把所有底部导航逐个点一遍，再在二级页面点所有"回首页""去购物车"之类的按钮，看有没有报错、有没有页面白屏、底部高亮对不对。

第三，如果在做多端适配，分别在目标平台的真机上过一遍，尤其是路径大小写、中文路径这两类问题，开发者工具经常靠不住。

第四，检查所有从服务端下发的跳转链接。这类链接通常会带一个type字段标明跳转方式，改页面结构时最容易漏改，而且出了问题往往是线上才有反馈。

switchTab:fail can not switch to no-tabBar page这条报错本身不难解决，难的是它背后暴露出来的"页面身份散落在各处"的结构问题。我个人的经验是，与其每次遇到都去翻app.json，不如花半天把跳转入口统一收口到工具函数里，把 tabBar 路径抽成常量，把fail日志全部补上。这三件事做完，这个报错在你的项目里基本就绝迹了。真正会反复折磨人的，永远是那些"不报错但参数丢了""不报错但数据是旧的"的隐性问题，而它们的解法，都藏在onShow和那一次归一化处理里。