pinia 适合电商购物车复杂选中逻辑，应分层管理基础粒度、分组和临时选中态，联动操作需上下文校验，派生状态用 getters 统一计算，持久化需区分用户行为与自动推导状态。

在大型电商购物车中，选中状态不是简单的“全选/全不选”，而是涉及商品规格差异、库存限制、优惠分组、跨店铺结算等多层逻辑。Pinia 的设计天然适合这种复杂性——关键不在“能不能管”，而在“怎么组织才不乱”。

按业务维度拆分选中逻辑

不要把所有选中状态塞进一个 selectedIds: Set<string></string> 里。真实场景中，用户可能只选某 SKU、某规格组合、某店铺下的部分商品，甚至“选中但暂不结算”。推荐分层管理：

• 基础粒度选中：每个唯一商品项（含 ID + 规格哈希）独立控制，用 Map<string boolean></string> 存储，避免数组遍历性能问题；
• 分组选中：如按店铺 ID 或优惠活动 ID 建立 groupSelected: Record<string boolean></string>，支持“勾选整店商品”；
• 临时选中态：比如“结算前预校验”时的临时勾选，不写入持久化数据，用局部 ref 或 store 内 transient state 管理。

选中联动必须带上下文校验

用户点击“全选”，不是无脑设为 true。真实业务中需考虑：

Ainative Vue Sdk

使用 `@ainative/vue-sdk` 为 Vue 3 应用添加 AI 聊天功能。适用于以下场景：(1) 安装 `@ainative/vue-sdk`，(2) 在 Vue 组件中使用 `useChat` 组合式函数，(3) 提供……

下载

• 库存不足的商品不能被选中（即使 UI 显示可勾），action 中应先 filter 掉 stock 的项；
• 不同店铺商品可能不支持合并结算，全选需按店铺分组处理，而非统一 toggle；
• 已下架或失效商品应自动取消选中，并提示用户（通过 action 返回操作结果或触发 notification）。

用 getters 暴露计算态，而非在组件里算

选中相关的派生状态（如“当前选中多少件”“选中商品能否使用某张优惠券”）必须收敛到 store 的 getters 中，理由很实际：

• 多个组件（商品列表、顶部工具栏、结算页）都需要读取相同逻辑，复用 getter 避免散落的 .filter(...).reduce(...)；
• Pinia 的 getter 具备响应式缓存，比每次 computed 更高效；
• 类型安全：配合 TypeScript，getter 返回类型自动推导，比如 selectedItems: CartItem[]，组件直接解构使用，不需再断言。

持久化与同步要区分“选中”和“行为”

刷新页面后，用户期望“之前勾选的还在”，但这个“在”是有条件的：

• 仅持久化 用户主动操作产生的选中状态（如点击 checkbox），不保存因全选/反选自动推导的状态；
• 服务端返回的商品列表变更（如下架、调价）后，本地选中 ID 若找不到对应项，应在加载后自动清理，避免脏状态；
• 跨端同步（如 App 和 H5）建议用事件驱动：选中变更 → emit event → 其他端监听并更新本地视图，而不是强求状态完全一致。

不复杂但容易忽略的是：选中不是布尔值开关，它是业务规则的出口。Pinia 的优势在于让你把规则写清楚、收得拢、改得快，而不是堆逻辑。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！