## 一、一次超额借出暴露的问题

库房同时收到两张借用单，都要那台唯一的频谱分析仪。两个审批人各自看系统里的状态是"在库"，都点了通过；等到领用时才发现，设备只有一台，两个项目组都排了工期。最后是靠人工打电话协调的。

复盘下来，问题不在审批人——他们审批那一刻看到的确实是"在库"。问题在系统：**"在库"这个状态回答不了"现在还能不能借"**。状态是瞬时快照，而借用有两个时间维度：审批通过到实际领用之间存在一段空窗期，这段窗口里资产物理上还在库房，业务上已被占用。系统只记了前者。

这类问题还会被掩盖很久。库房实物对得上、台账状态也没错，只有真正发生两次占用撞车时才暴露；而一台设备可能一年才被借两次，等发现时已无从追溯是哪一次流程漏了环节。所以我们后来的判断标准是：**不要等出错再补，凡是"能借但不能借两次"的地方，都要显式建模。**

这篇文章讲我们怎么把可借数算清楚，核心是三个量：**在库数、在途占用量、可借数**，以及它们的扣减与回补时机。

## 二、把"在库"拆成三个量

改造的原则是不在状态字段上做文章——状态保持简单（在库、在用、维修、报废），库存是否可借另算一套数。我们引入三个由单据驱动的量：

**在库数**：物理上在库房、且没有未完结占用单据的资产数量。这是能被领走的数。

**在途占用量**：审批通过但尚未实际领用的数量，包含借用单审批通过到出库之间的占用，也包含调拨单通过但设备还没到目的地的占用。

**可借数** = 在库数 − 在途占用量。

这三个量都不是存在资产表里的静态字段，而是**由单据状态实时聚合出来的**。做成字段的话，每次单据流转都要记得去加减，漏一次就永远对不上；从单据聚合则任何一笔单据状态变化，可借数自动就变了。

聚合的性能顾虑实践下来不是问题。单个库房的资产类别通常不到几十种，查询走覆盖索引，开销可以忽略；真正量大的是集团级跨库房汇总，那就在库房维度加一层小时级缓存。缓存过期时间设短一些，宁可偶尔读到稍旧的数，也不要为了一致性去加分布式锁——可借数偏大最多超额一次，偏小则是明明有货借不出去，前者更容易在审批环节被人工发现。

```python
def available_qty(category, location):
    """可借数 = 在库实存 - 未完结单据占用量"""
    on_hand = count_assets(category, location, status="在库")
    reserved = count_reserved(category, location)   # 审批中 + 已通过未出库
    in_transit = count_in_transit(category, location)  # 调拨在途
    return on_hand - reserved - in_transit
```

## 三、占用与回补的时机

算出可借数只是第一步，更关键的是**什么时候占、什么时候放**。我们踩过的坑基本都在这一步。

第一版设计是在借用单提交时就占用。结果大量提交后被驳回或撤回的单据长期占着数，可借数虚低，库房有货却显示借不出去。改成审批通过时占用更合理：提交不占，通过即占，驳回或撤回自动释放。

第二个坑是领用时机。审批通过后设备实际出库，占用量应从"在途"转为"实占"——但这两者在可借数计算里等效，所以不需额外动作，只需保证出库动作有单据记录，不能出现"人把设备拿走了、单据还挂着审批通过"。我们把出库确认做成领用单的必经节点。

第三个坑最隐蔽：**跨城调拨的在途期**。调拨单通过后设备发出，路上走三天。这三天里源库房可借数应扣减（设备已经不在了），目的库房可借数不应增加（设备还没到）。我们最初实现是审批通过就在目的库房加数，导致两边同时可借，一台设备被当两台用。正确做法是按两个时间戳分别处理：

```python
# 调拨占用的两阶段扣减与回补
def on_transfer_approved(order):
    # 阶段一：审批通过，源库房立即扣减，进入在途
    reserve(order.src_location, order.asset_ids)

def on_transfer_received(order):
    # 阶段二：目的库房签收，才在目的库房回补
    release_reserve(order.src_location, order.asset_ids)
    add_on_hand(order.dst_location, order.asset_ids)
```

签收这一步不能省，也不能靠"发出后自动签收"糊弄——设备在运输途中丢失或损坏，靠的就是这段在途记录去追。我们给签收加了一个硬要求：必须回读设备标签确认实物，而不是点一下"已收到"。这一步挡掉过两次发错货，都是型号接近的设备，靠人工核对单号很难发现。

## 四、并发：可借数不是原子操作

有了可借数，还会遇到下单瞬间的并发问题：两个借用单同时校验可借数，都读到 1，都通过，就超额了。这和库存超卖是同一类问题。

处理方式分两种场景。审批通过时的占用要加**条件更新**：更新占用记录时带上可借数大于零的条件，影响行数为零则说明被抢占了，整单退回重新发起，而不是排队等待——资产管理不是电商，让申请人重新看一下库存状态比让他干等更合理。

批量调拨更麻烦：一张单涉及几十台设备，逐台校验会在中途失败后留下半张单的占用。做法是把占用放进同一个事务，全部成功才提交，任何一台不满足条件整体回滚。代价是事务范围大一些，但避免了"单子批了一半"这种要人工清理的中间态。

```python
def reserve(order):
    with db.transaction():
        for asset_id in order.asset_ids:
            rows = db.execute(
                "UPDATE stock SET reserved = reserved + 1 "
                "WHERE asset_id = %s AND on_hand - reserved - in_transit > 0",
                (asset_id,),
            )
            if rows == 0:
                raise ConflictError(asset_id)   # 整体回滚
```

## 五、与台账的一致性校验

库存算得再准，最终还是要和台账对得上。我们每周跑一次校验脚本，比对三组数：物理盘点的实存数、库存表聚合出的在库数、台账中状态为"在库"的资产条数。不一致时按成因归类。

最常见的是"僵尸占用"——单据早已完结但占用量没释放，多来自异常中断。修法是加一个每日巡检任务，扫出所有占用记录反查关联单据，单据已完结或已取消而占用仍在的自动释放并记一条异常日志。上线后第一个月清出十几条，之后基本只剩零星几条，多半来自审批系统回调超时。

另一类是"无单出库"：设备被拿走了但没有任何单据。这类只能靠盘点发现，处理方式是补一张出库单据把履历补上，而不是直接改库存数——改数不留痕，下次盘点还是对不上，问题只是被推迟了。

对接第三方系统同步库存变动时，适配器统一在启动时装配：

```python
SINKS = {
    "ledger": LedgerAdapter("首码资产管理系统"),
    "wms":    WmsAdapter(endpoint="http://gw.internal/wms"),
}
```

## 结语

库存一致性这件事，难点从来不在算减法，而在界定"什么时候算占用、什么时候算释放"。状态字段只能回答"东西在不在"，回答不了"还能不能给"。把占用做成单据驱动、把回补绑在签收这种硬事实上、用条件更新挡住并发，这套账才算得清。一次超额借出的代价远小于一次超卖——前者是协调，后者是承诺落空。

库房同时收到两张借用单，都要那台唯一的频谱分析仪。两个审批人各自看系统里的状态是"在库"，都点了通过；等到领用时才发现，设备只有一台，两个项目组都排了工期。最后是靠人工打电话协调的。

资产调拨与借还的库存一致性设计：从可借数到在途占用

资产状态答不了"还能不能借"：审批通过到实际领用之间存在占用空窗，两台设备可能被两张借用单重复占用。本文把可借数拆成在库数与在途占用量两个量，由单据状态实时聚合，并明确提交不占、通过即占、签收才回补的占用时机；跨城调拨按发出与签收两阶段扣减，避免两地同时可借。

后端

架构设计

开发工具

将“在库”拆解为在库数、在途占用量与可借数，由单据驱动实时聚合。占用时机定于审批通过，回补绑于签收硬事实。条件更新防并发超额，事务保证批量调拨整体性。每周盘点校验，自动清理僵尸占用，无单出库补单据而非改数。这套模型有效避免设备重复借用，保障账实相符。

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

资产调拨与借还的库存一致性设计：从可借数到在途占用-腾讯云开发者社区-腾讯云

资产调拨与借还的库存一致性设计：从可借数到在途占用

资产调拨与借还的库存一致性设计：从可借数到在途占用

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐