解构 Pinia store 会丢失响应性，因其脱离 Proxy 追踪链；storeToRefs 将 state/getters 转为 ref 以维持响应式，actions 可直接解构调用。
直接解构 Pinia store 会丢失响应性，因为解构出来的变量是普通 JS 值，脱离了 Vue 的 Proxy 响应式追踪链；storeToRefs 的作用就是把 state 和 getters 转成 ref，让解构后的字段仍能触发视图更新。
为什么解构 store 会“失活”？
Pinia store 底层用 reactive 包裹，所有字段都靠 Proxy 拦截访问。一旦写 const { count } = store，相当于执行 const count = store.count——得到的是那一刻的快照值（比如数字 0），后续 store.count 变了，这个 count 不会同步，也不触发重渲染。
storeToRefs 怎么“续命”？
它不是复制值，而是为每个 state 字段和 getter 创建一个 ref，内部通过 toRef(store, key) 绑定原始路径。解构后拿到的是 ref，读写需走 .value（模板中自动解包）：
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
const { count, doubleCount } = storeToRefs(useCounterStore())-
count.value修改等价于store.count++，响应链完整 -
doubleCount.value是只读计算值，随count自动更新
哪些可以不用 storeToRefs？
actions 是普通函数，Pinia 已绑定 this 到 store 实例，解构后调用依然有效：
立即学习“前端免费学习笔记（深入）”；
-
const { increment } = useCounterStore()→increment()没问题 - 但别误以为
increment是响应式数据——它只是个函数，不参与依赖收集 - state 和 getters 必须用
storeToRefs，否则响应性中断
什么时候该用？什么时候不用？
不是所有场景都需要解构：
- 模板里直接写
{{ store.count }}最简洁，无需额外处理 - script 中频繁读写同一字段（比如多个
computed或事件回调），用storeToRefs提升可读性 - 传给
computed或watch时，必须用ref形式，否则监听不到变化
