Pinia作为Vue应用里的状态管理工具，用起来是真的顺手。但用顺手了不代表用对了，很多开发者在日常编码中不注意细节，就会让应用变得卡顿。这篇文章我就从实际问题出发，聊聊Pinia容易踩的性能坑，以及怎么优化。这些坑我自己也踩过，比如一个store里放了一堆数据，结果改一个字段整个页面都跟着重新渲染，鼠标都卡得动不了。所以想把这些经验分享出来，帮大家少走弯路。
一、Pinia性能问题的常见来源
Pinia的核心是响应式数据。当store里的数据一变，所有用到这些数据的地方都会跟着更新。这原本是好事，但如果你把不该做成响应式的数据也放进store，那就会带来额外的计算和内存开销。比如有些常量、配置项，其实不需要实时更新，但放进store后，Vue就会为它们建立依赖追踪，白白增加负担。你可以想象一下，本来只需要管理一个小组件的数据，结果你把整个公司的数据都塞到了一个仓库里，每次改动都要通知一堆人，效率自然低。
常见来源主要有几个：一是store定义得太大，什么数据都往里塞；二是组件里直接解构store，导致响应性丢失或者过度绑定；三是在模板里频繁调用getters或actions，形成不必要的计算；四是忽略了Pinia自身的缓存机制。这些问题在项目初期不明显，因为数据量小，等到页面多、组件多、交互复杂了，性能就慢慢露馅了。
二、几个容易踩的性能坑
2.1 一个store塞进所有东西
很多人习惯把用户信息、菜单、页面数据全都放进一个store里。这样做表面上是方便，但每个数据都是响应式的，只要有改动，整个store的依赖都会重新检查。尤其是团队协作时，别人改了一个字段，结果所有使用这个store的组件都可能被波及。比如你只改了用户头像，购物车组件明明没用到头像，但因为它也订阅了同一个store，可能就会跟着重新计算一遍，这就是浪费。
下面是个反面例子：
// Vue 3 + Pinia 示例：巨大的store
import { defineStore } from 'pinia'
import { ref } from 'vue'
export const useBigStore = defineStore('big', () => {
// 用户信息
const user = ref({})
// 菜单列表
const menu = ref([])
// 各种业务数据
const orderList = ref([])
const productList = ref([])
// 甚至连页面配置都放这儿
const theme = ref('light')
const fontSize = ref(14)
// 这里可能有几十个ref
return { user, menu, orderList, productList, theme, fontSize }
})
这种写法在简单项目里还好，但一旦数据量大起来，每次修改都可能让没用到的组件也跟着重新渲染。我自己就见过一个项目，一个store里存了二十多个ref，每次点击一个按钮，页面要顿一下才响应，就是因为响应式依赖太多了。
2.2 组件里直接解构store
在Vue组件里，很多人喜欢这样写：
// Vue 3 + Pinia 示例：错误解构
import { useUserStore } from '@/stores/user'
export default {
setup() {
const userStore = useUserStore()
// 直接结构成普通变量，丢失了响应性
const { name, age } = userStore
// 这样解构出来的name和age，后续修改不会触发页面更新
return { name, age }
}
}
直接解构userStore出来的name和age，会丢失响应式绑定。因为Pinia的state是通过vue的reactive实现的，解构后就成了普通值，没法实时同步。这样就会导致数据改了页面不更新，或者页面更新了数据没改，非常坑。正确的做法是用storeToRefs来解构，这个后面会详细说。
2.3 在模板里频繁调用getters
有些开发者为了省事，直接在模板里调用getters，比如计算总价。getters本身有缓存，但如果你在模板中多次调用，每次调用如果参数不同，缓存就失效了，还得重新计算。更常见的是，你明明只需要一个计算好的值，但因为你每次在模板里写表达式，它就会额外做一次运算。
<!-- Vue 3 + Pinia 示例：模板中频繁调用 -->
<template>
<div>{{ cartStore.totalPrice }}</div>
<div>{{ cartStore.totalPrice + cartStore.shipping }}</div>
</template>
这里totalPrice被用了两次，但第二次运算时又得重新读取，如果getters内部逻辑复杂，性能就会变差。虽然Vue的模板编译有时候会做一些优化，但你不能指望它每次都帮你搞定，所以最好把这种计算放到纯粹的JavaScript逻辑里。
三、优化技巧大放送
3.1 用storeToRefs精准解构
既然直接解构会丢响应性，那就用storeToRefs来解构，这样拿到的是ref对象，既能更新，又不会多绑定无关数据。storeToRefs有点像给store做了一次“响应式快照”，只把state和getters转成ref，actions还是保留原样。这样组件就只对用到的属性建立依赖，其他字段更新时，这个组件不会受影响，性能自然就上去了。
看这个正确写法：
// Vue 3 + Pinia 示例：storeToRefs正确用法
import { useUserStore } from '@/stores/user'
import { storeToRefs } from 'pinia'
export default {
setup() {
const userStore = useUserStore()
// 只拿需要的属性，其他不影响
const { name, age } = storeToRefs(userStore)
// 注意：actions不能通过storeToRefs解构，会丢失方法上下文
const { updateName } = userStore
return { name, age, updateName }
}
}
这样name和age就是ref对象，在模板里直接使用name，在JavaScript里用name.value，都不会丢失响应性。而且这个组件只关心这两个字段，其他字段变化时不会触发它的更新。它的优点是代码清晰、性能可控；缺点是每次都要写storeToRefs，如果习惯解构的话容易漏掉。不过为了性能，这点小麻烦值得。
3.2 把小store拆成多个store
既然大store有性能隐患，那就拆开。比如用户信息单独一个store，购物车单独一个，订单单独一个。拆开后，每个store的依赖范围都变小了，修改一个不会影响到别的。这也是符合软件工程里的“单一职责原则”，让store各管各的事。
示例：两个store分开管理
// Vue 3 + Pinia 示例：拆分后的用户store
import { defineStore } from 'pinia'
import { ref } from 'vue'
export const useUserStore = defineStore('user', () => {
const name = ref('张三')
const age = ref(30)
function setAge(val) {
age.value = val
}
return { name, age, setAge }
})
// Vue 3 + Pinia 示例：拆分后的购物车store
import { defineStore } from 'pinia'
import { ref } from 'vue'
export const useCartStore = defineStore('cart', () => {
const goods = ref([])
function addGoods(item) {
goods.value.push(item)
}
return { goods, addGoods }
})
这样每个store职责单一，更新时互不干扰，性能自然好。拆store的过程其实也能帮你理清业务逻辑，比如发现某个功能模块的数据经常一起变，而且其他模块不依赖，那就果断拆出来。不过别拆得太碎，否则组件里要引十几个store，管理反而麻烦。
3.3 用getters做缓存计算
getters类似于Vue的计算属性，会自动缓存结果，只要依赖项不变，就不会重新计算。所以把复杂的计算放进getters里，比在组件里写计算逻辑要好。因为组件里的计算属性只在组件实例上存在，如果好几个组件都需要同一个计算结果，你不可能在每个组件里都写一遍，而getters是全局共享的，计算一次，所有地方都能用缓存。
示例：购物车总价用getters
// Vue 3 + Pinia 示例：getters缓存总价
import { defineStore } from 'pinia'
import { ref, computed } from 'vue'
export const useCartStore = defineStore('cart', () => {
const goods = ref([
{ name: '苹果', price: 5, count: 2 },
{ name: '香蕉', price: 3, count: 3 }
])
// 这个getters会缓存，只要goods不变，就只算一次
const totalPrice = computed(() => {
console.log('重新计算总价') // 添加日志可以看到何时重算
return goods.value.reduce((sum, item) => sum + item.price * item.count, 0)
})
return { goods, totalPrice }
})
适用场景是那些计算复杂、调用频繁的数据，比如统计报表、格式化价格等。它的优点很明显：性能好，代码复用度高；缺点是不太适合异步操作，如果getters里需要异步请求数据，还是建议放到actions里。另外，getters的缓存是依赖响应式数据的，如果你在getters里返回了一个新的对象，那每次访问都会生成新引用，缓存就失效了，要注意避免。
3.4 用shallowRef和markRaw减负
有些数据很庞大，比如图表配置、富文本内容，它们不需要深层响应式。这时候可以用shallowRef或者markRaw来告诉Vue“别管我一层以下的变化”。Vue的响应式默认是深层的，如果你把一个很大的对象放进store，它会递归地把所有属性都变成响应式，这非常消耗内存。用markRaw可以跳过这个转换，让对象保持原始状态。
示例：markRaw处理非响应式数据
// Vue 3 + Pinia 示例：markRaw减少响应式开销
import { defineStore } from 'pinia'
import { ref, markRaw } from 'vue'
export const useEditorStore = defineStore('editor', () => {
// 这个配置对象不会在模板中动态变化，就用markRaw包裹
const config = ref(markRaw({
toolbar: ['bold', 'italic'],
theme: 'light'
}))
// 其余需要响应式的数据照常写
const content = ref('')
return { config, content }
})
注意一点：markRaw包装过的数据，即使修改了里面的属性，Vue也不会去检测，适合那些只赋值一次、后面就不再变的静态资源。shallowRef也是类似，它只让最外层的value变成响应式，内部的改动不触发更新。这两个工具用得好，能明显减少内存占用，但用错了就会让数据失去响应性，导致页面不更新。所以使用前一定要确认这个数据确实不需要深层响应式。
四、注意事项和应用场景
用这些优化技巧时，要结合项目实际。比如新项目一开始就拆好store；老项目可以慢慢迁移。storeToRefs和getters是基础操作，建议每天都用，养成好习惯；markRaw和shallowRef则要看数据的使用方式，别盲目乱用，不然容易让数据失去响应性，后面调试起来很头疼。
每个技巧都有它的场景：store拆分适合业务模块清晰的情形，比如用户、购物车、订单各自独立；getters适合有复杂计算且频繁读取的场景，比如总价、数量统计；markRaw则适合那些体积大但不变的数据，比如地图配置、第三方SDK初始化对象。在小型项目里，过度的优化反而增加维护成本，所以要先测量再优化，别一上来就堆技巧。可以用Vue Devtools里的性能面板看看哪个store更新频率高，再针对性优化。
另外，Pinia本身还有一些工具插件，比如官方提供的pinia-plugin-persistedstate，如果使用不当也可能拖慢性能。比如持久化时需要序列化整个store，数据量一大就会卡，所以尽量只持久化必要的数据。还有一点，在组件中尽量少用store.$subscribe，因为它对所有store变化都生效，频繁操作字段时会带来额外开销。
五、总结
Pinia本身很轻快，但用不好会拖慢应用。今天聊的这些坑和优化方法，都是日常开发中很容易遇到的。把store规划好，用对工具函数，保持数据最小可用，性能自然就上来了。记住这几个关键词：拆store、storeToRefs、getters缓存、markRaw减负。性能优化没有一招鲜，多观察应用的实际情况，在合适的地方用合适的手段，才是最好的做法。希望这些经验能帮你在开发中少踩坑，让应用跑得又快又稳。
评论
围绕“Pinia开发中常见的性能问题及优化技巧”参与讨论