解构 pinia store 会丢失响应性，因解构得到的是普通 js 副本，与原始 reactive 对象脱钩；storetorefs 通过为每个字段创建 ref 桥接响应链，保持响应性；actions 可直接解构调用，因其已绑定 store 实例。
解构 Pinia store 会丢失响应性，根本原因在于 Vue 的响应式追踪机制被切断了。
响应式依赖 Proxy 访问路径
Pinia 的 store 是用 reactive 包裹的对象，内部所有 state 和 getters 都通过 Proxy 代理实现响应式。Vue 的依赖收集只在「读取代理对象上的属性」时触发——比如写 store.count，Proxy 的 getter 就会被调用，从而建立模板或计算属性与该数据的响应联系。
一旦解构：const { count } = store
相当于执行了一次 const count = store.count，得到的是当时值的一个普通 JS 副本（如数字、字符串），它和原始 reactive 对象彻底脱钩。后续 store.count 改变，这个 count 不会更新，也触发不了视图重渲染。
storeToRefs 是怎么“保活”的？
storeToRefs 不是魔法，而是一种“桥接”：它遍历 store 中所有 state 字段和 getters，为每个都创建一个独立的 ref，并让这个 ref 的 .value 始终指向原始响应式数据的实时值。
- 返回的是
{ count: ref(store.count), doubleCount: ref(store.doubleCount) } - 你解构出的
count是一个 ref，读写必须用count.value（模板中自动解包） - 修改
count.value实际等价于修改store.count，响应链完整保留
actions 为什么不用 storeToRefs？
actions 是普通函数，Pinia 在创建 store 时已将它们 显式绑定到 store 实例（即 this 指向 store）。所以即使你解构出 increment，调用它仍能正确访问 this.count 等内部状态。
但注意：解构后的 action 仍是普通函数，不带响应性；它只是“能用”，不是“被响应式包裹”。因此不要把它和 state 混在一起解构，容易误以为它也需要 .value。
常见误区提醒
-
toRefs适用于reactive对象，而storeToRefs是 Pinia 专为 store 定制的增强版，会正确处理 getters 和嵌套结构 - 如果只在模板里用，直接写
store.count最简洁，无需解构 - 需要在 script 中多次读写某个字段，或要传给
computed/watch，才推荐用storeToRefs解构
