最直接有效的办法是所有状态变更必须通过action封装，禁止直接赋值store字段；需用storetorefs/computed读取，typescript设readonly和类型约束防误改。
最直接有效的办法是：所有状态变更必须通过 action 封装，禁止在组件中写 store.xxx = newValue 这类赋值语句。这不是“建议”，而是防止状态污染、提升可维护性的硬性约束。
为什么直接改 state 危险？
直接修改会绕过响应式追踪机制和业务逻辑校验，导致：
- 多个组件同时写同一字段时，更新顺序不可控，容易覆盖彼此的修改
- 资金、订单等关键模块里，误把计算结果（如趋势值）赋给余额字段，引发连锁数据错乱
- 调试困难——错误发生在某个组件的某行赋值，但影响却出现在另一个页面的渲染或 API 请求中
- DevTools 无法记录变更来源，$subscribe 监听不到裸赋值操作
用 action 封装变更逻辑
每个修改动作都应有明确语义和边界控制。比如：
- 不要在组件里写
fundStore.balance = newBalance - 而应调用
fundStore.updateBalance(newBalance)，内部做校验、日志、防抖或联动更新冻结金额 - 批量操作统一走原子 action：
cartStore.bulkUpdateItems(items)，避免循环中多次 patch
配合 storeToRefs + computed 读取，切断直接引用
组件中读取状态时，也需注意方式：
- 用
const { balance } = storeToRefs(fundStore)获取响应式引用，而不是fundStore.balance - 对派生数据，优先用
computed(() => store.xxx)，确保依赖追踪准确 - 避免解构后直接赋值：
const { balance } = fundStore; balance = 100—— 这不会触发响应式更新，且破坏响应链
类型与结构上提前设防
借助 TypeScript 和 Pinia 的定义机制，在编码阶段就减少出错可能：
- state 使用只读接口（
readonly）声明字段，让 IDE 提示不可赋值 - 在 store 定义中显式写出 action 类型，例如
updateBalance: (val: number) => void - 关键字段（如
balance、orderStatus）不暴露 setter，只提供带校验的 action
