Pinia 的状态合并逻辑：同名 State 如何处理？

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