推荐方式依次为：在 actions 中封装修改逻辑（最安全）、用 $patch 批量更新、用 storetorefs 解构后修改；不推荐直接裸赋值。
Pinia 的 state 可以直接修改，但“能做”不等于“该做”。真正安全、可维护的修改方式，核心在于**响应性保持 + 逻辑收口 + 变更可追溯**。以下是三种实际可用的方式，按推荐程度排序：
用 storeToRefs 解构后修改（适合简单同步更新）
直接解构 store.xxx 会丢失响应性，必须用 storeToRefs() 包一层：
- 在组件中导入：
import { storeToRefs } from 'pinia' - 解构时写成：
const { count } = storeToRefs(store)（注意count是 ref） - 修改时加
.value：count.value++或count.value = 100
这种方式适用于单个字段、无业务逻辑、临时调试等轻量场景，但不便于复用和追踪。
在 actions 中封装修改逻辑（强烈推荐）
把所有状态变更逻辑统一收进 actions，是 Pinia 最佳实践：
- 定义时写在 store 文件里：
actions: { increment() { this.count++ } } - 组件中调用：
store.increment()（this指向当前 store，自动绑定） - 支持异步操作，比如先请求再更新：
async fetchUser() { const res = await api.getUser(); this.userInfo = res; }
好处很明显：逻辑集中、便于单元测试、搜索 action 名就能定位所有修改点、避免多处散落赋值导致状态混乱。
用 $patch 批量更新多个字段（适合配置类或表单提交）
当一次要改 3 个以上 state 字段，又不想写多个 action 时，$patch 更简洁：
- 写法：
store.$patch({ name: '张三', age: 25, city: '杭州' }) - 它内部是浅合并，不会覆盖未传的字段
- 注意：不能用于嵌套深层对象的精细更新（此时建议用 action + 结构化逻辑）
适合初始化、表单重置、跨字段联动等批量操作场景。
不推荐直接写 store.count = 5 这类裸赋值——虽然语法合法，但绕过了逻辑层，后期排查数据异常时很难溯源。动作越小，越要守住边界；状态越关键，越要走 action。
