pinia 不支持状态自动合并，同名 store id 会报错，同名字段在不同 store 中互不影响；需跨 store 访问数据时应通过 getters 显式读取，而非 $patch 覆盖。
Pinia 本身不提供“状态合并”机制，同名 State 不会自动覆盖或合并，而是由开发者在定义 store 时明确控制。关键在于：每个 defineStore 是独立实例，它的 state 函数返回全新对象，不存在运行时的同名字段冲突问题。
同名 Store ID 会直接报错
如果两个 defineStore 使用了完全相同的字符串 ID（如都写 'user'），Pinia 在启动时就会抛出错误：Duplicate store id: "user"。这不是状态合并问题，而是注册冲突——ID 必须全局唯一。
- 解决方法是改用模块 URL 自动命名：
defineStore(import.meta.url, { ... }) - 或手动确保 ID 差异化，例如
'user/profile'和'user/settings'
同名字段在不同 Store 中互不影响
比如 useCartStore 和 useUserStore 都有 name 字段，它们各自独立、彼此隔离：
-
cartStore.name只属于购物车 store -
userStore.name只属于用户 store - 修改其中一个，另一个完全无感知
需要“逻辑合并”时，用 getters 显式读取
若想让某个状态“看起来像合并了”，比如在购物车中显示用户昵称和等级，不能靠 State 自动合并，而应通过 getters 主动拉取：
- 在 cart store 的 getter 中调用
useUserStore()获取实例 - 读取
userStore.name或userStore.level - Pina 自动追踪依赖，用户 store 更新后，cart 的 getter 也会重算
避免误用 $patch 或 $state 覆盖其他 Store
有人尝试用 $patch 把另一个 store 的 state “塞进来”，这是错误做法：
-
cartStore.$patch(userStore.$state)会把 user 的整个 state 对象混进 cart 的响应式结构里，破坏数据边界 - 可能导致类型错乱、调试困难、响应失效
- 正确方式始终是：跨 store 数据消费走 getters，变更走各自 actions
