拼豆云掌柜中，豆仓管理双仓实现是怎么做的？我们来讲解一下

拼豆行业中，对于豆的管理，我们有非常深刻的见解。下面我们给出双仓如何实现的具体方案：

## Key Changes
### 1. 数据与后端
– 给库存表和流水表增加 `warehouse_type` 字段，不复制整套表。
– `bead_inventory_stocks` 主键从 `(store_id, code)` 升级为 `(store_id, warehouse_type, code)`。
– `bead_inventory_movements` 增加 `warehouse_type`，相关索引带上该字段；流水仍保留 `in / out / adjust`。
– 库存查询、库存写入、最近变动、低库存判断全部按 `store_id + warehouse_type + code` 工作。
– 报表查询、CSV 导出、聚合计算全部增加仓过滤；首版要求传仓，不做隐式混合口径。
– 数据迁移脚本将历史 `stocks` 和 `movements` 全量回填为 `warehouse_type = ‘usage’`，并为 `staging` 预留空数据能力。

### 2. API / 类型合同
– `GET /bead-inventory` 增加必选或默认明确的 `warehouseType` 查询参数。
– `POST /bead-inventory/:code/movements` 请求体增加 `warehouseType`。
– `GET /bead-inventory/report` 和 `/report.csv` 增加 `warehouseType`。
– Web / miniapp / API 共用类型增加仓枚举，至少包括：
– `type WarehouseType = “usage” | “staging”`
– `BeadInventoryItem`、`BeadInventoryMovement`、`BeadInventoryReport` 返回体带当前仓上下文，或由请求上下文严格决定返回口径。
– 接口默认值要固定：未显式传仓时按 `usage` 处理，避免旧调用直接报错；但新前端实现必须显式传仓，避免以后混乱。

### 3. PC 端
– 现有“豆仓管理”保留为一个面板，不复制第二套页面。
– 在系列筛选上方增加一级仓切换：`使用仓`、`备货仓`。
– 切换仓时重新拉取该仓库存、低库存统计、最近变动、批量补货目标。
– 保留现有 PC 动作集：`入库 / 消耗 / 盘点`，只是所有动作都落到当前仓。
– `豆仓报表` 同样增加仓切换，默认进入 `使用仓`，下载链接也带仓参数。

### 4. 小程序端
– 现有豆仓页保留为一个页面，不复制分包页面。
– 顶部 hero 区或系列筛选上方增加一级仓 tab：`使用仓`、`备货仓`。
– 小程序首版保持当前动作集不变：`入库 / 盘点`，不顺手开放 `消耗`，避免超出这轮范围。
– 页面标题仍叫“豆仓管理”，仓 tab 负责区分管理对象，避免功能入口膨胀。
– 现有系列卡片、弹层、低库存统计、最近变动全部跟随当前仓刷新。

## Test Plan
– 后端 e2e：
– `usage` 和 `staging` 同一色号库存互不影响。
– 同一色号分别在两仓写入 movement，库存与最近变动按仓隔离。
– 报表按仓统计正确，CSV 与 JSON 一致。
– 历史未带仓数据迁移后全部落到 `usage`。
– Web 测试：
– 打开豆仓管理默认展示 `usage`。
– 切换到 `staging` 会重新请求并更新统计、卡片、流水。
– 提交 `in / out / adjust` 时请求带当前仓。
– 豆仓报表切仓后下载链接与查询请求都带当前仓。
– 小程序测试：
– 仓 tab 存在且切换后请求带当前仓。
– `usage` / `staging` 切换后系列统计、库存卡片、最近变动同步更新。
– 现有“只有入库/盘点”断言更新为“有仓 tab，但动作仍只有入库/盘点”。

## Assumptions
– 商用标准的核心是“账不混、口径一致、两端统一”，因此不接受仅前端加 tab 但后端仍单仓的方案。
– 首版不做仓间调拨；若后续要做，应作为新动作单独设计成一次事务内双流水，而不是再复制表或复制页面。
– 安全线按仓独立存储，不共用同一个阈值。
– 这轮只覆盖豆仓管理与豆仓报表，不顺手改其他消耗来源或自动扣仓逻辑。