pinia状态管理需组件主动配合：读取用storetorefs保持响应性，变更统一走actions，卸载时手动清理$subscribe和$onaction；跨平台需注意持久化与环境差异。
组件处理全局响应式状态，核心是“用对方式读、管好时机写、生命周期里清”。Pinia 本身不绑定组件，但组件必须主动配合——读取要保持响应性，变更要走 actions，清理要落在卸载前。
保持响应式读取：用 storeToRefs 解构
直接解构 store 的 state 会丢失响应性，因为解构后变量脱离了 Vue 的响应式追踪系统。
- ✅ 正确做法：用
storeToRefs提取 ref 包裹的状态 - ❌ 错误示例：
const { userInfo } = useUserStore()→ userInfo 变成普通对象，更新不触发视图重绘 - ✅ 推荐写法：
const { userInfo } = storeToRefs(useUserStore())→ userInfo 是 ref，变化自动同步 - 补充：getters 和 actions 可直接解构，它们本身不依赖响应式代理
触发状态变更：统一走 actions，避免直接改 state
Pinia 鼓励将业务逻辑封装在 actions 中，既保证可测试性，也便于集中拦截（如日志、错误处理、权限校验）。
- 异步操作天然支持：
async login() { this.user = await api.login(); } - 多个状态联动更清晰：比如登录成功后同时设置
token、userInfo、lastLoginTime，都在一个 action 内完成 - 避免在组件中直接写
store.$patch({ ... })或store.token = 'xxx'，这会让逻辑分散、难以维护
组件卸载时清理副作用：订阅与监听必须手动取消
Pinia store 没有内置生命周期钩子，它的“存活”取决于是否被引用。但组件内建立的响应式连接（如 $subscribe、$onAction）不会随组件销毁自动释放，必须显式清理。
- 在
onUnmounted中调用订阅返回的取消函数 - 例如：
const unsubscribe = store.$subscribe(() => {...}); onUnmounted(unsubscribe); - 同理，
$onAction返回的也是可取消函数，同样需在卸载时调用 - ⚠️ 不要用
store.$dispose()替代——它会彻底销毁 store 实例，仅适用于路由切换后该 store 确实再无任何引用的极少数场景
跨平台或复杂场景：注意运行时差异与持久化边界
尤其在 Uniapp 等跨端项目中，组件对全局状态的使用还需考虑环境限制。
- 小程序没有
localStorage，若用了pinia-plugin-persistedstate，需配合条件编译提供不同持久化方案（如 Taro 的Taro.setStorageSync） - App 或小程序后台切前台时，组件可能复用但 store 已过期，可在
onShow（Uniapp）或onActivated（Vue）中主动刷新关键状态 - 避免在 setup 中直接访问
window或document，这些在非 H5 平台会报错；状态读写应完全通过 store 抽象
