计算属性名配合常量不能实现redux风格状态管理——它仅是语法糖，不解决action派发、响应更新、不可变性等核心问题；需结合usereducer（vue 3）或watch+dispatch（vue 2）及显式函数调用才能模拟redux行为。
计算属性名配合常量不能直接实现 Redux 风格的状态管理——它只是语法糖，不是状态机制本身。 常量 + 计算属性名（如 [TYPES.INCREMENT]）只解决“怎么写 key”，不解决“怎么派发 action”“怎么响应更新”“怎么保证不可变性”这些核心问题。
为什么 [CONSTANT] 不能替代 action.type 判断逻辑
很多人以为把常量塞进计算属性名，就能自动触发 reducer 分支。其实不然：Vue 的计算属性或响应式对象里用 [TYPES.ADD_ITEM] 只是动态生成一个 key 名，跟 Redux 的 action 派发、reducer switch 完全无关。
常见错误现象：
— 写了 { [TYPES.SET_LOADING]: true }，但 loading 状态没响应变化
— 在 computed 里用 [TYPES.COUNT] 当 getter 名，结果组件不更新
- 计算属性名只影响对象结构，不影响响应式依赖追踪（Vue 2 中尤其明显）
- Redux 风格要求 action 是普通对象，且必须被
store.dispatch()显式调用；[TYPES.X]不会自动变成 action - 若在
data或ref中直接用计算属性名初始化状态，后续无法靠该 key 触发依赖更新（Vue 3 的reactive对初始 key 敏感）
真正在 Vue 里模拟 Redux 的最小可行组合
要接近 Redux 行为，得靠三样东西协同：常量定义 key、useReducer（Vue 3）或手动 watch + Object.assign（Vue 2）、以及显式 dispatch 函数。
使用场景：需要集中管理跨组件状态，又不想引入 Vuex/Pinia，且团队熟悉 Redux 模式
-
TYPES常量只用于统一字符串，避免拼写错误，比如export const TYPES = { INCREMENT: 'INCREMENT' } - 状态更新必须走函数调用，例如
dispatch({ type: TYPES.INCREMENT, payload: 1 })，而不是直接改state[TYPES.INCREMENT] - Vue 3 推荐用
useReducer+computed暴露派生状态；Vue 2 只能靠watch监听 action 队列 + 手动合并 - 性能影响：每次 dispatch 都应返回新对象（
{ ...state, [TYPES.COUNT]: state[TYPES.COUNT] + 1 }），否则 Vue 响应式失效
简短示例（Vue 3）：
const [state, dispatch] = useReducer(reducer, { [TYPES.COUNT]: 0 });<br>function reducer(state, action) {<br> switch (action.type) {<br> case TYPES.INCREMENT:<br> return { ...state, [TYPES.COUNT]: (state[TYPES.COUNT] || 0) + 1 };<br> default:<br> return state;<br> }<br>}
[TYPES.X] 在 mutation 名/字段名中的实际用途和坑
它唯一稳妥的用法，是作为 mutation 类型字符串或响应式对象的字段名，但必须配合明确的更新逻辑。
参数差异：
— mapMutations([TYPES.INCREMENT])（Vuex）中，TYPES.INCREMENT 是字符串，会被映射为方法名
— { [TYPES.INCREMENT]: handler }（自定义事件监听）中，它是 key，handler 不会自动绑定到 store
- 兼容性风险：Vue 2 的
data()返回对象若含[TYPES.X]，初始化时若TYPES.X未定义，会静默失败（不报错但 key 为undefined） - 不要在
computed的 getter 名里用计算属性名，如computed: { [TYPES.DATA]() { return this.$store.state.data } }—— Vue 不支持动态计算 getter 名 - 调试时容易误判：看到
state[TYPES.LOADING]为true，就以为“已触发 loading”，其实可能只是手动赋值，没走任何流程控制
真正难的不是怎么写 [TYPES.X]，而是怎么让每次状态变更都经过同一入口、可追溯、不可跳过中间逻辑。常量只是贴在门上的标签，门后面有没有人守着、有没有登记本，才是关键。
