Pinia中关于计算属性与storeToRefs的hydration问题解析

问题现象

在使用Pinia状态管理库时，开发者可能会遇到一个特定的错误："proxy set handler returned false for property"。这个错误通常发生在以下场景：

1. 在Nuxt.js应用中使用了Pinia
2. 在store中定义了计算属性(computed)
3. 使用storeToRefs将计算属性从一个store传递到另一个store
4. 应用进行hydration(水合)过程时

具体表现为：页面初始渲染时能正确显示计算属性的值，但在hydration过程中会抛出上述错误。

问题根源

这个问题源于Pinia 2.2.5版本中的一个变更，该变更与计算属性的处理方式有关。核心问题在于：

• 计算属性本质上是只读的(getter-only)
• 当使用storeToRefs时，它会尝试创建一个响应式引用
• 在hydration过程中，Vue尝试设置这些属性值，但由于它们是计算属性，导致设置操作失败

技术背景

在Vue 3的响应式系统中：

1. 计算属性(computed)创建的是只读的响应式引用
2. toRef和storeToRefs会创建可写的引用
3. 当尝试写入一个计算属性时，Vue会阻止这个操作并抛出错误

这个问题在Vue 3.5.0-alpha.3中开始出现，而在之前的alpha.2版本中则不会发生，这表明这是Vue核心团队有意为之的行为变更。

解决方案

根据Pinia核心团队的回应，正确的做法是：

1. 避免直接传递计算属性：不要使用storeToRefs来传递计算属性
2. 使用计算属性包装：如果需要在另一个store中使用计算属性，应该创建一个新的计算属性来引用原始值

// 正确做法
export const useSecondaryStore = defineStore('secondaryStore', () => {
    const testStore = useTestStore();
    
    // 创建新的计算属性来引用原始值
    const testComputed = computed(() => testStore.testComputed)

    return {
        testComputed
    }
})

3. 使用skipHydrate：作为临时解决方案，可以使用skipHydrate来标记这些属性，避免在hydration过程中尝试设置它们

最佳实践

1. 明确属性用途：在设计store时，明确区分可写状态和计算属性
2. 谨慎使用storeToRefs：只在需要解构可写状态时使用storeToRefs
3. 考虑使用getter函数：对于只读数据，考虑使用普通函数而非计算属性
4. 版本兼容性检查：注意Pinia和Vue版本的组合可能带来的行为差异

总结

这个问题揭示了Pinia和Vue响应式系统交互中的一个重要细节：计算属性的只读特性与storeToRefs的预期行为之间的冲突。理解这一点有助于开发者更好地设计store结构，避免在应用hydration过程中遇到意外错误。

对于需要跨store共享计算结果的场景，推荐使用计算属性包装或直接引用原始store的方法，而不是通过storeToRefs传递计算属性本身。这种做法不仅解决了hydration问题，也使代码意图更加清晰。