我朋友小伍的 Pinia 困惑：把所有产品数据放一起不行吗？

大家好，我是奈德丽。

昨天我朋友小伍找到我，他是什么情况呢？和我同一年毕业的，做了一段时间C#，后来转成运营了，经常要日夜班颠倒，身体可能也受不了了，后来报了前端培训班，但是培训班学完呢，留给自己的是一大堆视频资料，但是最近他也按照我的建议去做了一个实战项目，用到的技术栈是Vue3，在实战过程中对于pinia的设计存在一些疑问

小伍的疑问和他的"完美"设计

小伍在电话里兴奋地跟我说："奈德，我觉得我想明白了！既然 Pinia 是用来管理全局状态的，那我把所有产品相关的数据都放到一个 store 里不就行了吗？这样多方便啊！"

然后他给我展示了他的想法，甚至还加上了他刚学的持久化插件：

javascript 复制代码

import { defineStore } from 'pinia'
import { ref } from 'vue'

const useProductStore = defineStore('product', () => {
  // 产品基础信息
  const products = ref([])
  const categories = ref([])
  
  // 用户相关
  const userCart = ref([])
  const userFavorites = ref([])
  const userHistory = ref([])
  
  // 库存价格
  const inventory = ref({})
  const prices = ref({})
  
  // 统计数据
  const salesData = ref({})
  
  function fetchProducts() { /* 获取产品 */ }
  function addToCart(productId) { /* 添加购物车 */ }
  function updateStock(productId, stock) { /* 更新库存 */ }
  
  return { /* 所有数据和方法 */ }
}, {
  persist: {
    key: 'product-store',
    storage: localStorage,
    // 把所有数据都存到 localStorage 里！
    paths: ['products', 'userCart', 'userFavorites', 'userHistory', 'inventory', 'prices']
  }
})

小伍满脸期待地问我："你看，我还用了 persist 插件，这样用户刷新页面数据也不会丢！是不是很完美？一个 store 解决所有问题，还能持久化存储！"

我看着他那期待的眼神，心想：完了，这小子不仅要把所有数据放一个 store，还要把所有数据都存到 localStorage 里...

我先肯定了他的学习态度

"小伍，你这个想法其实很正常，我刚学 Pinia 的时候也是这么想的。而且你能想到用 persist 插件，说明学习很用心。"

我跟他分析了这种做法确实有一些优点：

开发便利性方面，对于刚学 Pinia 的人来说，只需要记住一个 store 的名字，所有产品相关的操作都在这里，确实降低了学习成本。加上 persist 插件，数据持久化也一步到位了。

数据一致性方面，当用户购买商品时，需要同时更新库存、购物车、销售统计等多个数据。如果这些数据都在一个 store 里，确实能保证数据的一致性。

用户体验方面，用了 persist 插件后，用户刷新页面或者重新打开网站，之前的购物车、浏览历史都还在，体验确实还行。

小伍听了之后更兴奋了："对吧！我觉得我这个设计简直完美！"

但我要给他泼点冷水了

"不过小伍，你这个设计有几个问题，可能会让你后面很头疼。"

首先是性能问题会被放大。我跟小伍解释："你把所有数据放在一个 store 里，本来就有性能问题。现在又用了 persist 插件，每次数据变化不仅要触发组件重渲染，还要写入 localStorage。"

javascript 复制代码

// 每次库存更新都会触发
function updateStock(productId, newStock) {
  inventory.value[productId] = newStock
  // 1. 所有使用 useProductStore 的组件都会重新渲染
  // 2. persist 插件会把整个 inventory 对象写入 localStorage
  // 3. localStorage 的写入是同步操作，会阻塞主线程
}

"想象一下，如果你的库存数据每 10 秒更新一次，每次更新都要把整个库存对象写入 localStorage。如果库存数据有几千个商品，这个写入操作会很慢，用户会感觉页面卡顿。"

小伍皱了皱眉："这么严重吗？"

然后是存储空间的浪费。"localStorage 有大小限制，通常是 5-10MB。你把产品信息、库存数据、用户行为数据全部存储，很容易超出限制。而且有些数据根本不需要持久化。"

我给小伍举例：

javascript 复制代码

// 这些数据真的需要存储吗？
const salesData = ref({})      // 销售统计 - 这是实时数据，不需要缓存
const inventory = ref({})      // 库存信息 - 这是服务端数据，应该实时获取
const prices = ref({})         // 价格信息 - 可能随时变化，缓存可能导致显示错误价格

// 真正需要持久化的可能只有这些
const userCart = ref([])       // 购物车 - 用户期望刷新后还在
const userFavorites = ref([])  // 收藏夹 - 用户期望刷新后还在

persist 插件的正确使用姿势

"那 persist 插件应该怎么用呢？"小伍问道。

我跟他分享了一些实践经验：

首先要区分哪些数据需要持久化。不是所有数据都需要存储，要根据业务场景判断：

javascript 复制代码

// 用户个人数据 store - 需要持久化
const useUserStore = defineStore('user', () => {
  const userInfo = ref({})
  const preferences = ref({})
  
  return { userInfo, preferences }
}, {
  persist: {
    key: 'user-data',
    storage: localStorage,
    paths: ['userInfo', 'preferences']  // 只存储必要数据
  }
})

// 购物车 store - 需要持久化
const useCartStore = defineStore('cart', () => {
  const cartItems = ref([])
  const favoriteItems = ref([])
  
  return { cartItems, favoriteItems }
}, {
  persist: {
    key: 'cart-data',
    storage: localStorage  // 默认存储所有数据
  }
})

// 产品信息 store - 不需要持久化
const useProductStore = defineStore('product', () => {
  const products = ref([])
  const categories = ref([])
  
  return { products, categories }
  // 注意：这里没有 persist 配置
})

其次要选择合适的存储方式：

javascript 复制代码

// 临时数据用 sessionStorage
const useFilterStore = defineStore('filter', () => {
  const currentFilters = ref({})
  const searchHistory = ref([])
  
  return { currentFilters, searchHistory }
}, {
  persist: {
    key: 'filter-data',
    storage: sessionStorage,  // 关闭浏览器就清除
    paths: ['currentFilters'] // 搜索历史不需要存储
  }
})

// 重要数据用 localStorage
const useCartStore = defineStore('cart', () => {
  const cartItems = ref([])
  
  return { cartItems }
}, {
  persist: {
    key: 'cart-data',
    storage: localStorage     // 长期保存
  }
})

性能优化的考虑

我继续跟小伍解释性能问题：

"除了存储问题，你的大 store 设计还有个隐患。persist 插件默认是在数据变化时立即写入存储，如果数据变化频繁，会严重影响性能。"

javascript 复制代码

// 问题场景：实时更新库存
const useProductStore = defineStore('product', () => {
  const inventory = ref({})
  
  // 如果这个函数被频繁调用
  function updateInventory(updates) {
    Object.assign(inventory.value, updates)
    // persist 插件会立即将整个 inventory 写入 localStorage
    // 如果 inventory 数据很大，这个操作会很慢
  }
  
  return { inventory, updateInventory }
}, {
  persist: {
    storage: localStorage,
    paths: ['inventory']  // 每次更新都会触发存储
  }
})

"更好的方案是把频繁变化的数据和稳定的数据分开：

javascript 复制代码

// 稳定数据 - 可以持久化
const useUserPreferenceStore = defineStore('userPreference', () => {
  const favorites = ref([])
  const settings = ref({})
  
  return { favorites, settings }
}, {
  persist: true  // 这些数据变化不频繁，可以安全持久化
})

// 动态数据 - 不持久化，每次重新获取
const useRealTimeStore = defineStore('realTime', () => {
  const inventory = ref({})
  const prices = ref({})
  
  return { inventory, prices }
  // 不使用 persist，避免频繁写入存储
})

小伍的新疑问

小伍听了我的解释，若有所思："那如果我想要缓存产品信息怎么办？每次进入页面都重新获取太慢了。"

这是个好问题。我跟他分享了一些缓存策略：

"可以使用有时效性的缓存，而不是简单的持久化：

javascript 复制代码

const useProductCacheStore = defineStore('productCache', () => {
  const products = ref([])
  const cacheTimestamp = ref(0)
  const CACHE_DURATION = 30 * 60 * 1000  // 30分钟
  
  function isExpired() {
    return Date.now() - cacheTimestamp.value > CACHE_DURATION
  }
  
  async function getProducts() {
    if (products.value.length === 0 || isExpired()) {
      // 缓存过期，重新获取
      const data = await fetchProductsFromAPI()
      products.value = data
      cacheTimestamp.value = Date.now()
    }
    return products.value
  }
  
  return { products, getProducts }
}, {
  persist: {
    storage: localStorage,
    paths: ['products', 'cacheTimestamp']
  }
})

这样既能享受缓存的好处，又能保证数据的时效性。

我的建议：渐进式优化

最后，我给小伍总结了一个渐进式的优化方案：

"你可以先从你现在的设计开始，然后根据实际遇到的问题逐步优化：

第一阶段：基础拆分

javascript 复制代码

// 先把用户数据和产品数据分开
const useUserStore = defineStore('user', () => {
  const cart = ref([])
  const favorites = ref([])
  return { cart, favorites }
}, { persist: true })

const useProductStore = defineStore('product', () => {
  const products = ref([])
  const inventory = ref({})
  return { products, inventory }
})  // 暂时不持久化

第二阶段：细化持久化策略

javascript 复制代码

// 根据数据特性选择不同的持久化方案
const useCartStore = defineStore('cart', () => {
  const items = ref([])
  return { items }
}, {
  persist: { storage: localStorage }
})

const useSessionStore = defineStore('session', () => {
  const filters = ref({})
  return { filters }
}, {
  persist: { storage: sessionStorage }
})

第三阶段：性能优化 根据实际使用情况，进一步拆分高频变化的数据和低频变化的数据。"

小伍点点头："明白了，我先按现在的方式实现基本功能，然后根据实际情况调整。"

关于 persist 插件的一些坑

最后，我还提醒小伍一些使用 persist 插件时容易遇到的问题：

"有几个坑你要注意：

数据格式兼容性：如果你修改了 store 的数据结构，localStorage 中的旧数据可能会导致错误。需要考虑数据迁移策略。

存储容量限制：localStorage 空间有限，要监控存储使用情况，避免超出限制。

隐私和安全：敏感数据不要存储在 localStorage 中，因为它是明文存储的。

跨域问题：不同域名下的 localStorage 是隔离的，这在某些场景下可能会有问题。"

写在最后

和小伍的这次交流让我想起了自己学习 Pinia 和 persist 插件时的经历。每个人在学习新技术时都会有"把所有功能都用上"的冲动，这很正常。

重要的是要理解每个工具的适用场景，不是因为有这个功能就一定要用，而是要根据实际需求来选择。persist 插件很好用，但不是所有数据都需要持久化；大 store 开发起来很方便，但不是所有数据都应该放在一起。

架构设计没有标准答案，只有适合当前场景的解决方案。对于初学者来说，从简单开始，在实践中发现问题，然后不断改进，这可能是最好的学习路径。

希望小伍能在实践中找到属于自己的最佳实践，也希望这次的分析能帮到更多正在学习 Pinia 的朋友。

各位佬，点个小赞吧，之后我会分享更多有趣的前端内容，预计下一篇文章的内容是更加深入Pinia，源码篇。

恩恩......懦夫的味道。