一次看似普通的 BUG 修复，怎么就撞上了 ECMAScript 规范和 Vue 源码？

把问题收拢，用户能感知到三类异常：

• 切子页签异常：点了"行程"，高亮却落在"生活"上；
• 跳错目的地：从分享链接进入时，明明带的是 tab=行程，落地却停在默认页签；
• 返回误显：从详情页点"返回"，激活页签与离开前不一致。

抽丝剥茧后我们发现，激活状态的判定同时依赖了三个数据源——URL Query、localStorage、sessionStorage，三者的优先级从未被明确定义。每一次"看似普通"的修复，其实都在触碰下面这些隐藏的机制。

...route.query 并不是单纯的语法糖，而是 ECMAScript 规范定义的"数据属性复制"操作 CopyDataProperties。

// 拷贝当前路由的全部 query，再覆盖 tab
router.replace({ ...route.query, tab: '行程' })

它的运行机制分三步：

1. 1遍历源对象自身的可枚举属性；
2. 2对每个属性触发 [[Get]] 读取值；
3. 3通过 CreateDataPropertyOrThrow 写入目标对象。

关键结论是：基本类型按值复制，引用类型按引用地址复制——这就是浅拷贝。为什么这里不用深拷贝？因为 route.query 是扁平结构（Record<string, string>），深拷贝不但无意义，还会让 Vue 响应式 Proxy 丢失、剥离 undefined，并带来不必要的性能开销。浅拷贝是性能与语义兼具的正确选择。

很多人以为 router.replace({ query }) 会"聪明地"把新旧 query 合并一下，实际上 Vue Router 内部执行的是整体覆盖——相当于 currentQuery = newQuery，而不是 Object.assign。

// ❌ 错误：只传 tab，hideTab / showBack / lang 等上下文参数被整体丢弃
router.replace({ query: { tab: '行程' } })

// ✅ 正确：先浅拷贝旧参数，再覆盖 tab
router.replace({ query: { ...route.query, tab: '行程' } })

如果直接传 { tab, localtab }，原有的 hideTab、showBack、lang 等上下文参数会被彻底丢弃。{ ...route.query, tab } 提前把旧参数浅拷贝过来，是确保路由上下文不丢失的标准写法。

Vue 虚拟 DOM 通过 isSameVNodeType(n1, n2) 判断节点能否复用，核心条件就是 type === type && key === key。

function isSameVNodeType(n1, n2) {
  return n1.type === n2.type && n1.key === n2.key
}

当 key 变化时，Vue 会认定这是全新节点：立即销毁旧组件（Unmount：移除 DOM、清理响应式监听、触发 onUnmounted），再挂载新组件（Mount：初始化 setup、触发 onMounted、插入 DOM）。

缺陷根因就在这里：若 App.vue 里的 <router-view> 把 route.fullPath 当 key，只要 Query 发生任何微小变化，fullPath 就跟着变，旅行页组件就被强行"无意义销毁 + 重建"，onMounted 里的状态初始化逻辑反复执行，放大状态错乱。

<keep-alive :include="..."> 匹配的是组件自身的 name 选项（组件定义里的 name: 'Travel'），而不是路由配置里的 name。

// include 匹配的是组件 name，不是路由 name
<keep-alive :include="['Travel']">
  <router-view :key="route.fullPath" />
</keep-alive>

一旦旅行页组件内部没有显式声明 name，或名称与白名单不一致（如写成了 TravelNoKeepAlive），它就命中不了 include，KeepAlive 缓存直接失效。在失去缓存保护的情况下，再叠加 fullPath 作为 key，任何路由参数变化都会让整个页面被打回原点、从头重构。

watch(() => tab.value, cb) 内部用 Object.is 比较新旧值：

// Vue 内部比对逻辑
if (!hasChanged(newValue, oldValue)) return

当 tab.value 默认值是 'LocalLife'，而 URL 解析出的值恰好也是 'LocalLife' 时，新旧值完全一致，Watch 回调不会触发。如果更新 localStorage 的逻辑写在 Watch 回调里，localStorage 就得不到及时刷新，旧脏数据继续残留，成为下一次启动的"污染源"。

结论：作为"状态缓存"，localStorage 天生不适合存当前会话的激活状态；sessionStorage 的隔离模型才与"当前 WebView 生命周期"对齐。

• 全局守卫 router.beforeEach：注册后全局生效，生命周期与 Router 实例绑定，组件销毁时不会自动解绑，容易逻辑泄露；页内改 Query 也会触发全局拦截，引发不必要的计算。
• 组件级守卫 onBeforeRouteLeave：仅在离开当前路由记录时触发（只改 Query 不会触发），并随组件销毁自动注销，语义精准、无内存泄漏风险。

三大缺陷的根因是：激活状态同时依赖 URL、localStorage、sessionStorage 三个数据源，优先级混乱。修复方案是确立清晰的优先级机制：

激活状态 = URL Query ‖ sessionStorage ‖ 默认状态

1. 1URL Query 为最高优先级事实源：深链跳转、分享链接直接决定初始状态；
2. 2sessionStorage 为次级降级源：无 URL 参数时退而读取当前会话上下文，摒弃强污染的 localStorage；
3. 3默认值保底：确保任何边界条件都有合法兜底状态。

下面的实验台把这三层优先级做成可交互的版本，你可以随意修改三个数据源，观察修复前后最终激活页签的差异。

回头看，这次修复真正的收获不是改对了几行代码，而是逼着自己把四个"理所当然"的认知重新校准了一遍：... 是规范级浅拷贝、router.replace 是整体覆盖、Diff 的 key 是身份标识、KeepAlive 的 include 匹配的是组件 name。工程里没有真正的"小改动"，只有还没被追到底的根因。