三层真不算深，但筛选项这种"父层持有、子层读写"的状态，确实是最适合抽出来的一类。先说结论：先 provide/inject 封一个 composable，真要跨路由或者要持久化再换 Pinia，因为换了以后调用方一行都不用改。

先说那个"响应式容易丢"的说法，这多半是从 Vue2 时代传下来的。Vue3 里只要你 provide 的是 ref/reactive/computed，天然就是响应式的，坑在别的地方：

• provide('filters', reactive({...})) 没问题，但子组件里 const { status } = inject('filters') 就解构丢了——reactive 解构出来的是普通值。想省事就 toRefs，或者干脆别解构，用 filters.status。
• 直接 provide 一个普通对象、普通字符串，那确实不响应，得包成 ref。
• 用 Symbol 当 key，别用字符串，不然重名了很难查，TS 也能有类型提示。

我的习惯是把 provide 和 inject 都收进一个文件，组件里只调 useFilters()：

// useFilters.js
const KEY = Symbol('filters')

export function provideFilters() {
  const filters = ref({ status: '', keyword: '' })
  provide(KEY, {
    filters: readonly(filters),          // 只读，防止子组件偷偷改
    setFilter: (k, v) => (filters.value[k] = v),
    reset: () => (filters.value = { status: '', keyword: '' }),
  })
}

export function useFilters() {
  const ctx = inject(KEY)
  if (!ctx) throw new Error('useFilters 必须在 provideFilters 的子树内使用')
  return ctx
}

关键点是状态只读、改动走方法。很多人 provide 出去一个 reactive 直接让子组件随便改，短期爽，时间长了就变成隐式双向绑定，谁改的完全查不到，比 props 还难维护。

provide/inject 真正需要注意的就三条：组件一旦被挪到 provider 外面就报错（上面那个 throw 能帮你早点发现）；它跟组件树生命周期绑死，路由切走了状态就没了，想缓存得自己想办法；还有就是它只对"后代"生效，兄弟组件之间传不了。

Pinia 的坑主要是另一个方向：

• 它是单例。同一个组件在一页里复用多次，状态就串味了，这种情况只能靠 provide/inject 做实例级隔离。
• 组件卸载了 store 还在，得手动 reset，不然下次进来还带着上次的筛选条件，这 bug 挺常见。
• 什么都往里塞，最后 store 变成大泥球，改一个字段不知道谁在响应。

所以判断标准挺简单：这个筛选条件只服务于当前这块组件树，路由一走就该清空 → provide/inject。它要被别的路由、侧边栏、导出功能读到，或者要同步到 URL、localStorage、要 devtools 看历史 → Pinia。

还有个容易被忽略的第三选项：把筛选条件同步到 route.query，表格直接读 route.query，改筛选就是 router.replace。好处是刷新不丢、能分享链接、浏览器后退能用，代价是频繁输入要防抖。做列表页的话这个其实最省心。

顺便说，这三层 props + emit 冒泡如果能忍，说明层级还浅；真到了"改一次崩一次"的程度，就是该抽 state 的信号了。先用 composable 包起来，将来迁 Pinia 只改内部实现，调用方感知不到，这是最稳的走法。

先说个可能有点反直觉的：这个问题的关键其实不在"隔了几层"，而在这份筛选状态该活多久、归谁管。想清楚这个，选型基本就定了。

中间层其实是无辜的

props 真正的痛点不是"写得啰嗦"，而是中间那两层被迫知道自己不该知道的东西。表格要的筛选条件，跟中间那个卡片、那个布局容器一点关系都没有。provide/inject 解决的正是这个——顺带跨层级，但核心价值是"解除无关组件的耦合"。所以别把"三层"当成要不要用的理由，三层真不多。

provide/inject 有一点经常被忽略：它是"作用域"

provide 在哪个组件调用，这份状态就跟着那棵子树一起生、一起死。组件卸载，状态自然回收，不用你操心。

Pinia 是模块级单例——全局一份。这里最容易踩的坑是：哪天页面里出现了第二个筛选面板（列表页里弹个抽屉做二次筛选、同一个组件被复用两次、页签切换保留两个视图），它们会共享同一份筛选条件，改一个另一个跟着变，还很难查。

所以有个很实用的判断句：这份状态是"全局唯一"还是"每个实例一份"？ 如果是后者，provide/inject 几乎是唯一选择，Pinia 硬上会疼。

同事那句"响应式容易丢"，其实站不住

Pinia 里 const { status } = useFilterStore() 一样丢响应式，一样得 storeToRefs。这是响应式框架的通病，不是 provide/inject 的专属问题，所以它不足以构成"上 Pinia"的理由。

什么信号出现，才真的该上 Pinia

• 要跨路由/跨页面共享（左侧栏折叠、用户信息、购物车）
• 要脱离组件树访问——路由守卫、axios 拦截器、定时器、onMounted 之外的模块代码
• 要持久化（localStorage / sessionStorage，Pinia 插件生态成熟）
• 状态变更来源非常分散，需要统一收口

这四条里占一条，Pinia 就合理了。

但上了 Pinia，这里有笔隐形账

• 作用域问题回到上面第二条
• 测试都要多一步（provide/inject 是包一层 provider，Pinia 是 setActivePinia(createPinia())），Pinia 更容易在用例之间串状态
• 隐式依赖变强：子组件直接 useStore() 就改了，谁改的不好追。provide/inject 至少还要求你显式 useFilters()，依赖关系还算摆在明面上

我实际项目里的分层做法

不是二选一，是按"生命周期"分层：

还有一个中间态很值得知道：如果筛选条件本来就应该跟着 URL 走（刷新能恢复、链接能分享给同事），那答案既不是 provide/inject 也不是 Pinia，是 router 的 query。不少人先上了 Pinia，做了一半才发现自己真正想要的是这个。

一句话口诀："它会不会同时存在两份？会不会离开这棵组件树？会不会要活过刷新？" 三个都是"否"，provide/inject 就够，别急着引 Pinia。

这个问题被“隔了几层”带偏了。层数其实是结果，不是原因——真正让 emit 崩的，是同一份筛选状态有好几个写入方。

先数写入方，别急着选库

一个筛选面板通常有几个地方会改它：输入框、下拉、重置按钮、快捷筛选标签、分页切换、URL 回填、外部带参跳转……7 个写入方，每个都要自己找一条回到顶层布局的路，中间层还得逐个转发。这不是“层级深”的锅，是数据流没有单一入口的锅。

所以先做一件事：把“谁能改筛选”收敛成一个函数。只要写入点收敛了，中间层转发几次其实不那么疼。收敛完再谈放哪——往往你会发现两个方案都不用上。

更省事的做法：把 provide 的距离压成 1 层

如果筛选面板和表格本来就是同一块业务的两半，可以让筛选组件自己 provide，把表格当插槽收进来：

<!-- FilterPanel.vue -->
<template>
  <div class="panel">
    <input v-model="filters.keyword" />
    <button @click="reset">重置</button>
    <!-- 表格从这里塞进来，它就在 provide 的下一层 -->
    <slot :filters="filters" :set-filter="setFilter" />
  </div>
</template>

然后最外层布局只写：<FilterPanel><DataTable /></FilterPanel>。

DataTable 不管被布局埋多深，它到状态源永远只隔一层——因为它根本不在布局的子树里，它是插槽内容。这个技巧比纠结选哪个状态库管用得多，代价为零，也不用给团队讲新概念。

但如果筛选该活过刷新，它就不属于组件树，也不属于 Pinia

这是最容易被忽略的一类：筛选条件天然是 URL 的一部分。用户刷新要保留、要能分享链接、要能按后退键退回上一组条件——那唯一真相就是 route.query，组件树和 store 都只是它的缓存。

// useFilters.js
export function useFilters() {
  const route = useRoute(), router = useRouter()
  const filters = computed(() => ({
    status: route.query.status ?? '',
    keyword: route.query.keyword ?? '',
  }))
  const setFilter = (k, v) =>
    router.replace({ query: { ...route.query, [k]: v || undefined } })
  return { filters, setFilter }
}

这样表格拿到的是一个 computed，谁改都走 setFilter，中间层连 emit 都不用写。

坑提醒：别在 input 每次按键都 replace，会刷爆路由；输入框用本地 ref + 300ms 防抖再同步，或者配 router.push 但接受历史堆积。另外数组/对象要自己序列化，敏感条件别塞 URL。

Pinia 真正的加分项是调试，不是解耦

前两位应该都讲了单例、作用域、持久化。我补一个实际项目里权重很高的点：devtools。

• provide/inject 在 Vue Devtools 的组件树里是隐形的，出了 bug 只能 console.log 猜是谁改的。
• Pinia 有 timeline，每次 mutation 带调用栈，能一眼看出是“重置按钮”还是“分页回调”把 status 清空了。

筛选逻辑一旦超过 3 个字段 + 联动规则，这个差距非常明显。反过来说，如果你的筛选就是“两个输入框一个下拉”，为调试价值上 Pinia 不划算。

另外 Pinia 在非组件代码里能直接 useFilterStore()，provide/inject 不行。这是硬边界。

一句话决策

最后一条补充：如果页面可能出现“列表里再弹个抽屉做二次筛选”，那份状态是每个实例一份。Pinia 得写成 defineStore + 传 id 建实例，麻烦；而 provide/inject 天然跟着子树生灭。这种场景别硬上 Pinia。