核心是让状态变更可追踪、可复现、有约束，需通过单一数据源、受控通道（mutation/action）、原子方法、计算派生和工具固化来保障一致性。
核心是让状态变更可追踪、可复现、有约束。不靠自觉，靠机制。
用单一数据源替代分散副本
多个组件读写同一份数据时，若各自维护本地副本，极易出现不一致。必须把共享状态抽出来，放到一个明确的、唯一的源头里管理。
- 小型项目可用
reactive或ref创建全局 store，但需配套定义修改方法（如store.updateUser()），禁止直接赋值 - 中大型项目推荐 Pinia：天然支持模块划分、类型推导、插件扩展，且 store 实例本身是响应式的，无需额外包装
- 避免“伪共享”——比如把同一个对象传给多个组件后，各组件自行修改其属性，这仍属于多入口变更，不是真的一致性
所有变更必须走明确通道
不允许绕过约定直接操作状态。无论是同步还是异步，都要经过受控路径。
- 同步变更 → 提交 mutation（Vuex）或调用 store 方法（Pinia），确保逻辑集中、命名语义化（如
setLoading(true)而非state.isLoading = true） - 异步变更 → 全部收口到 actions（Vuex）或 store 中的 action 函数（Pinia），在成功/失败后才触发状态更新，不把 API 调用和状态赋值混在一起
- 禁止在组件内直接修改 store 的深层属性（如
store.user.name = 'xxx'），应提供原子级更新方法
派生状态走计算逻辑，不存冗余字段
需要“算出来”的值，就用 computed 或 getters，而不是另存一份可能脱节的数据。
立即学习“前端免费学习笔记（深入）”；
- 例如用户权限判断，不要存一个
isEditor布尔值，而应在 store 中用 getter 返回user.role === 'editor' - 表单校验结果、列表筛选后的数量、价格含税总额等，都应实时计算，避免手动同步带来的遗漏
- Pinia 的
store.$patch()或 Vuex 的 mutation 若涉及多个字段联动更新，优先封装成一个方法，而非分多次提交
借助工具固化约束习惯
人会疏忽，工具不会。把一致性保障嵌入开发流程。
- 启用 Vue Devtools，打开“Vuex/Pinia”面板，实时观察每次状态变更的来源（哪个组件、哪个 action、耗时多少）
- 在 store 中加入简单断言，比如
if (typeof payload === 'string') throw new Error(...)，提前拦截非法输入 - 对关键状态（如登录态、权限列表）编写单元测试，验证从初始化、变更到清空的全链路行为是否符合预期
