打开业务页面DevTools → Network 一刷新：同一个「拉全量选项」接口连着出现十几次。参数几乎一样，响应也几乎一样。第一反应通常是：「谁又在乱请求？说起来，」

如果你正好遇到这种情况。你会发现自己已经把缓存写进了 Store，但页面仍然频繁发起请求。为什么会出现这种“缓存已设，却频繁请求”的痛点？下面就来拆解原因，并给出一套不需要改动任何组件的方法。

页面到底在干什么？

中后台页面里经常有：搜索区的部门、分类、区域下拉；页面底部还有新建、编辑、流转等弹窗——弹窗里嵌着一样的选择器。

公共选择器往往这么写：

onMounted => {
getOptions
})
const getOptions = async => {
const list = await shares.getSharedList
options.value = toTree
}

父页面不关心数据来源。选择器可复用，看起来很干净。但问题隐藏在这份「干净」里：首屏挂载时每个实例都会触发一次请求，潜在请求次数等于实例数量。

“我们明明有缓存”却不管用

Store 已经做过「缓存为空才发请求」：

const getSharedList = async => {
if {
const res = await axios.get
sharedList.value = res.data.data
}
return sharedList.value
}

直觉上这很合理：第一次拉取后复用。线上却不买账——首屏仍然 N 次并发。老实说，

关键不在“有没有缓存”。而在缓存生效的时机。

1. Select_1 进入方法，length === 0发起请求 A
2. Select_2 几乎同时进入。请求 A 还没回来length === 0再发起请求 B
3. …，直到 Select_N
4. 若干毫秒后请求陆续返回。缓存才有值
5. 之后的调用才真正命中缓存

再看说白了，只能挡住“已经写完缓存之后”的调用，挡不住**飞行中**的并发。这不是 Vue 或 Pinia 的锅，而是异步世界里的经典竞态。

另一个加重项是：个别业务组件绕过 Store，自行 调用同一接口。即使 Store 缓存正确，也无法防护这条旁路。

容易走偏的三种改法

• . 父页面统一请求，接下来通过 props 往下传递数据。 能治，但要改所有选择器和使用方。与「选择器自取数」既有模式对着干，改动面大。
• . 把所有弹窗改成 懒挂载。 首屏更轻，是好调整，却不是根因方法。而且要处理 ref.open 等时序，一不小心就变成「点了没反应」。
• . 给每个选择器加本地防抖 / 本地缓存。 每个实例一份本地状态，只能挡住「多个实例同时首启」之外的重复请求。

true solution 是共享数据入口本身。要能处理并发，而不是让各个组件自己去做去重或懒加载。

从修法来看，In-flight Promise 单飞

This is a classic pattern: same resource → only one request flies at a time;subsequent callers reuse that Promise.

let sharedListPromise = null

const getSharedList = async => { if { return sharedList.value // 已有缓存 }

if { // 没有正在进行中的请求 sharedListPromise = => { const res = await axios.get if { sharedList.value = res.data.data } return sharedList.value }).finally => { sharedListPromise = null // 无论成功失败都释放锁 }) }

return sharedListPromise // 调用直接返回 Promise }

• A: 有已有缓存 → 同步返回，无需网络；B: 请求正在进行 → 返回同一个 Promise；其实，C: 没有缓存且无正在进行 → 发起唯一一次网络请求。并把 Promise 暴露给后续调用者。

再看注意，此处无需修改任何组件。它们仍然保持 onMounted => getSharedList) 的写法。其实，只要多实例同时喊叫，Store 就只放行一次网络层面的大门。

如何落地到其它共享列表?

• ① # 将所有 “拉全量” 接口都包装成单飞模式。不过，
• ② # 对那些直接跳过 Store 调用 API 的业务组件做统一改造。让它们也走 Store 的单飞入口。
• ③ # 对需要强刷或带强参数的数据保持原始逻辑，不要误套单飞。

This改动为何划算?

• : 一处修改。全站共享列表受益，无需逐一改动组件。
• : 选型器继续自治。不必更换为 props 或 v-if 等手段，降低维护成本。
• : finally 总会清空锁。即使网络错误，下次还能重新尝试；成功后通过共享缓存避免重复调用。
• : 缓存负责结果、Promise负责过程。两者语义清晰，可读性高，