Vue3中用类存储状态是否合理？两种Pinia实现方案抉择

问题背景 #

我正在开发一个用Pinia做状态管理的Vue3应用，登录页的状态管理有两种实现思路：

1. 方案1：用类封装状态与逻辑
   Pinia Store代码：

   export const useLogInStore = defineStore("logInStore", () => {
     const logInSession = new AuthLogInSession();
   
     return {
        logInSession 
      }
   })
   

   对应的AuthLogInSession类：

   export class AuthLogInSession {
   
      email = ref<string>("");
      password = ref<string>("");
   
      constructor() {}
   
      isValid = computed<boolean>(() => {
         const isPasswordValid = this.password.value.length > 0;
         const isEmailValid = this.email.value.length > 0;
         return isPasswordValid && isEmailValid;
      });
   
      async logIn() {
         return await signInByEmailAndPassword(
         this.email.value,
         this.password.value);
      }
   }
   

   模板使用示例：

   <script setup>
   import { useLogInStore } from "~/stores/auth/login";
   
   const logInStore = useLogInStore();
   </script>
   <template>
     <button :disabled="!logInStore.logInSession.isValid"> Log in </button>
   </template>
   

2. 方案2：直接将状态与逻辑写在Pinia Store中
   省略独立类，把email、password、isValid计算属性、logIn方法直接放在defineStore的回调里。

想请教：哪种方案更合适？两种方案各有哪些潜在问题？有没有实践经验可以分享？

两种方案的对比与分析 #

方案1：类封装的优缺点与潜在问题 #

优点：

• 逻辑分离清晰，尤其在复杂登录流程（比如多步骤验证、第三方登录分支）下，类可以把相关状态和方法打包在一起，代码结构规整，后期维护时定位逻辑更方便。
• 类的复用性强，如果其他页面需要类似的登录会话逻辑，可以直接实例化或继承这个类。

潜在问题：

• 响应式陷阱：这是最突出的问题。虽然类内部用了ref和computed，但Pinia对类实例的响应式处理有局限——如果后续修改类实例的引用（比如重新赋值logInSession = new AuthLogInSession()），组件不会自动更新；若动态给类实例添加新的响应式属性，也可能导致响应式失效。
• 调试与DevTools支持差：Pinia DevTools对类实例的展示不如原生Store状态清晰，你无法直观看到类内部email、password的实时变化，调试效率低。
• 持久化兼容性差：如果用pinia-plugin-persistedstate这类插件做状态持久化，类实例会被序列化为普通对象，丢失方法和原型链，恢复时无法还原成原始类实例。

方案2：直接写在Pinia Store中的优缺点与潜在问题 #

优点：

• 原生响应式支持：完全贴合Pinia设计，所有状态和计算属性都能被完美追踪，响应式无隐患，组件能实时更新。
• 调试友好：DevTools可以清晰展示每个状态的变化轨迹，排查问题更高效。
• 持久化无阻碍：兼容各种Pinia持久化插件，状态能正常序列化和恢复。
• 团队协作成本低：符合Pinia官方推荐写法，熟悉Pinia的开发者能快速上手。

潜在问题：

• 逻辑臃肿：当登录流程变复杂（比如加入短信验证、密码找回、多场景登录判断），Store里的代码会越来越冗长，状态和方法混在一起，后期维护难度上升。
• 复用性弱：如果其他页面需要类似逻辑，只能复制代码或抽成工具函数，不如类的复用直接。

实践建议 #

1. 简单登录场景（仅账号密码登录）：优先选方案2，写法简洁，无响应式隐患，调试和持久化都省心。
2. 复杂登录场景（多步骤、多分支逻辑）：可以用方案1，但要规避响应式问题：
   • 不要修改类实例的引用，而是在类内部写重置方法（比如reset()），直接修改内部ref的值。
   • 如果需要持久化，不要直接持久化类实例，要么在Store里单独抽离需要持久化的状态，要么在类里实现toJSON()方法指定序列化内容。
   • 更推荐折中方案：把复杂逻辑抽成组合式函数，再在Pinia Store中调用，既保留逻辑分离，又享受Pinia的响应式支持。

折中方案示例：

// composables/useAuthLogIn.ts
export function useAuthLogIn() {
  const email = ref<string>("");
  const password = ref<string>("");
  const isValid = computed<boolean>(() => email.value.length > 0 && password.value.length > 0);
  
  const logIn = async () => {
    return await signInByEmailAndPassword(email.value, password.value);
  };

  const reset = () => {
    email.value = "";
    password.value = "";
  };

  return { email, password, isValid, logIn, reset };
}

// stores/auth/login.ts
export const useLogInStore = defineStore("logInStore", () => {
  const { email, password, isValid, logIn, reset } = useAuthLogIn();
  
  return { email, password, isValid, logIn, reset };
})

这种方式既实现了逻辑抽离，又保证了Pinia的响应式、调试和持久化支持，同时复用性也不受影响。

内容的提问来源于stack exchange，提问作者George