Pinia 很好用，但越好用的工具越容易被滥用。很多项目一旦引入 store，就会把页面里的所有状态都往里面放：弹窗开关、输入框内容、临时筛选条件、加载状态都变成全局状态。短期看似统一，长期会让状态来源变得模糊，页面销毁后状态还残留，问题排查也更困难。
一、先判断状态生命周期
我会先问一个问题：这个状态离开当前页面后还有没有意义？如果没有，它应该留在组件内。比如当前表单输入、临时弹窗开关、一次性的提交 loading，大多数情况下不需要进入 store。真正适合放进 Pinia 的，是用户信息、权限配置、当前班级、全局主题、跨页面共享的筛选上下文等。
生命周期越长，越适合 store；生命周期越短，越应该靠近使用位置。
二、store 要表达领域语义
store 不应该只是一个巨大的变量仓库。好的 store 应该围绕领域建模，例如 useUserStore 管用户身份和权限，useClassStore 管当前班级和班级切换，useSettingsStore 管全局配置。这样调用方知道自己依赖的是什么，也更容易定位状态更新入口。
能放进 store 不代表应该放进 store。状态归属越清楚，页面行为越可预测。
三、异步动作要避免隐式覆盖
store 里如果有异步 action，要特别注意并发和覆盖。比如用户快速切换筛选条件，旧请求晚回来可能覆盖新结果。解决方式可以是请求序号、取消请求、只接受最后一次结果，或者把关键状态留在页面内，让页面更明确地控制加载流程。
- 全局身份、权限和配置适合 store。
- 页面临时输入和弹窗状态优先留在组件内。
- store action 要命名为业务动作，而不是普通请求名。
- 需要持久化的状态要明确恢复时机和过期策略。
Pinia 的价值是让共享状态有清晰入口，而不是让所有状态都变成共享状态。克制使用，反而更能发挥它的作用。