Vuex 该什么时候上：不是所有共享状态都值得进 store

一提到 Vue 项目里的状态管理，很多人很快就会想到 Vuex。

这没问题。Vuex 在合适的场景下确实很有用，尤其是多组件共享、跨页面复用、状态流比较长的时候。

问题在于，Vuex 也特别容易被提早引入。

什么情况适合用 Vuex

如果一个状态同时满足下面几个条件，通常就值得考虑 Vuex：

• 多个组件都要读
• 修改入口不只一个
• 生命周期跨组件甚至跨页面
• 你希望状态流清楚可追踪

比如：

• 当前登录用户
• 权限信息
• 购物车
• 全局筛选条件

这些都比较适合放进 store。

什么情况不适合

如果只是一个页面里的弹窗开关、输入框内容、临时切换状态，这类局部交互通常没有必要上 Vuex。

不是说不能放，而是放进去之后成本会比收益高。

很多时候你会发现：

• mutation 要写
• action 要写
• getter 要写
• 最后只是改一个布尔值

这时大概率是建模层级抬高了。

Vuex 最有价值的地方是“明确”

很多人喜欢 Vuex，不只是因为它能共享状态，而是因为它把状态改动路径写得很明确。

你能知道：

• 状态在哪里
• 谁在改它
• 通过什么动作改

这种明确感在多人协作时尤其重要。

但别把所有状态都追求成“全局”

Vuex 的一个常见误用，就是把“会被复用”误解成“应该全局”。

有些数据确实有机会在别处再用，但如果眼下仍然只是一个局部页面的交互状态，就不一定要提前进 store。

越早全局化，后面越容易产生多余耦合。

module 拆分要早点做

项目稍大一些以后，store 最怕变成一个大对象，里面把用户、订单、设置、弹窗、缓存全揉在一起。

这时候最容易出现的问题不是功能失效，而是后面没人愿意动它。

所以模块拆分应该尽早做，不要等 store 已经长得很胖了再回头治理。

写在最后

Vuex 不该被神化，也不该被滥用。

它适合那些真正跨组件、跨页面、需要清晰流转的状态；至于局部交互，很多时候交给组件自己反而更自然。状态管理做得好不好，关键不是上没上 Vuex，而是状态层级是不是放对了。