标准答案
- 先判断状态是否真的需要全局共享。组件内部状态、表单草稿和一次性弹窗状态通常不需要放全局。
- 按业务领域拆 store 或模块，例如 user、permission、cart、settings，而不是做一个巨大 global store。
- 状态更新入口要收敛到明确 action，避免组件随意改全局对象导致数据流不可追踪。
- 服务端数据要考虑缓存、失效、刷新和请求状态，很多场景更适合交给专门的数据请求层。
- 持久化状态要控制范围和版本迁移，敏感数据不要直接存 localStorage。
题目解析
这道题考的是状态分层。全局状态不是越多越好，放错位置会让依赖关系、调试和性能都变差。
设计时可以从生命周期、共享范围、是否可持久化、是否来自服务端这四个维度判断。
通用状态模块还要关注选择器、订阅粒度、重置流程、权限变化和退出登录后的清理。
代码示例
一个清晰的状态模块会把状态和更新动作放在同一领域边界内。
JavaScript
const userStore = {
state: {
profile: null,
permissions: []
},
setProfile(profile) {
this.state.profile = profile
},
reset() {
this.state.profile = null
this.state.permissions = []
}
}常见误区
- 把所有接口返回、表单输入和弹窗状态都塞进全局 store。
- 组件直接修改全局状态对象，缺少可追踪的更新入口。
- 退出登录或切换租户时没有清理全局状态，导致数据串号。