多仓库独立核算的技术拆解

[系统设计]

多仓库独立核算的技术拆解：三级分组架构与实时查询优化

- - - - - - - - - - - -

一、一个被低估的工程难题

「多仓库核算」听起来像是业务需求，但从工程角度看，它牵涉到数据结构设计、计算过滤策略、分组聚合逻辑、前端渲染优化等一系列技术决策。

某工贸企业有5个仓库、2000个SKU，每月产生约8万条出入库流水。生成台账时需要支持：任意选择仓库组合、按仓库-分类-产品三级分组汇总、实时搜索定位任意产品、点击产品展示多仓库对比详情。

二、三级分组的数据结构设计

2.1 树形结构 vs 扁平结构

• 树形结构：嵌套对象，warehouse.categories.products三级嵌套。优点：层级关系清晰，展开/折叠操作简单。缺点：遍历和聚合需要递归，深度嵌套不利于搜索。
• 扁平结构+分组索引：所有产品记录存在一个扁平数组中，额外维护三个Map（warehouseMap、categoryMap、productMap）作为分组索引。优点：遍历性能好，搜索O(1)。缺点：需要额外维护索引一致性。

库存台账系统选择的是「扁平结构+分组索引」方案。原因：台账的主要交互是表格浏览和搜索定位，扁平结构更利于这两种操作。

2.2 分组索引的数据结构

▌ warehouseMap: Map<仓库ID, {name, summary, categoryIds}>categoryMap: Map<分类ID, {name, warehouseId, summary, productIds}>productMap: Map<产品ID, {name, categoryId, warehouseId, metrics}>

三级汇总（小计、合计、总计）在遍历流水时同步累加，无需二次聚合。

三、多仓库过滤：计算层过滤而非查询层过滤

策略	实现方式	优点	缺点
查询层过滤	同步数据时只拉取选中仓库的流水	数据量小，计算快	切换仓库需要重新同步
计算层过滤	同步全部流水，计算时按仓库ID过滤	切换仓库无需重新同步	遍历全部流水，略增耗时

系统选择计算层过滤。理由是：同步一次全部流水后，用户可以反复切换仓库组合，每次切换无需等待网络请求。额外的过滤开销只是O(n)遍历中增加一个if判断，对300ms的总耗时影响微乎其微。

四、200ms实时搜索：防抖策略与表格高亮

4.1 搜索的响应速度要求

用户在搜索框输入产品ID或名称，期望200ms内看到结果。实现的关键是防抖（Debounce）策略：

▌ 用户输入 -> 200ms防抖等待 -> 触发搜索 -> 扁平数组中遍历匹配 -> 更新表格高亮状态

200ms的防抖时间经过实测调优——过短（50ms）则每次按键都触发搜索，过长（500ms）则用户感知到明显的输入延迟。200ms是平衡点。

4.2 表格高亮的性能优化

• 使用CSS变量控制高亮状态，而非切换class——减少style计算
• 只更新可视区域的高亮状态，非可视区域延迟更新
• 搜索结果缓存：相同的搜索关键词复用上次的结果集

五、产品详情面板：多仓库对比与流水明细

• 第一层：台账汇总——该产品在选中仓库组合下的合计数据
• 第二层：多仓库对比——该产品在每个仓库的期初/入库/出库/期末对比
• 第三层：期间流水明细——该产品在统计期内的逐笔出入库记录

这三层数据在台账计算时已经同步生成，详情面板只是按产品ID从productMap和相关索引中取出数据，无需二次计算。面板的打开速度取决于DOM渲染而非数据准备。

六、超兔一体云：多仓库、多币种、多业务线的一体化管理延展

超兔一体云支持多仓库、多币种、多业务线的一体化管理。库存台账的多仓库独立核算是这种一体化的天然延展——不仅台账可以按仓库分别核算，进销存、收支账、生产工单也可以按仓库、业务线分别汇总。

更重要的是，超兔一体云的供应链模块将多仓库台账与采购、调拨、发货联动。当台账显示某仓库积压率过高时，管理者可以直接发起调拨单，将积压库存调往周转更快的仓库——数据和业务之间没有断层。

- - - - - - - - - - - -

本文从技术角度解析库存台账相关原理，供工贸企业选型参考。