# UniApp＋扫码：把资产卡片和现场盘点装进手机

机房里两台同型号笔记本，名字都叫“笔记本甲”，一台闲置，一台可能已经领走。拿着资产表找名称，很容易对错对象；设备上的唯一编号，才是现场和系统之间稳定的联系。

资产标签的价值，是让人找到这件设备以后，可以马上打开档案，核对位置和状态，再进入自己负责的工作。台账、报修、领用和盘点因此有了共同的入口。

这次用 RuoYi Office 的真实 UniApp 页面做浏览器仿真：模拟扫码回传编号，以历史教学数据回放资产详情，再展示盘点任务收到结果后的变化。没有调用手机相机，也没有连接真实后端写入；文中的PC画面另来自既有教学操作，分别标明。

![UniApp扫码连接资产识别、档案查询和现场盘点](https://developer.qcloudimg.com/http-save/yehe-12798805/44bf1313d3967345bf3e32dc1c0cf37e.png)

## 同一个编号，先打开的是这件资产

先看模拟扫码后的详情。资产编号 **ZC20261028-0001**，名称“AS02笔记本甲”，规格“教学便携款”，状态闲置，存放位置“AS01教学仓”。

![真实UniApp资产详情页面回放历史教学资产信息](https://developer.qcloudimg.com/http-save/yehe-12798805/2ed79860cf12fa3471f16090076f142b.png)

*[仿真截图] 430×932完整浏览器视口。真实产品页面使用教学数据响应；不是手机相机或在线数据库验证。*

手机端没有把PC资产台账的所有字段搬过来。先让人识别资产，再给出基本信息、存放位置和使用信息，底部保留报修、领用/借用入口。进入相应操作时，页面把当前资产ID带给后续表单，减少再次翻列表选设备的步骤。

这里有两个不同的标识：标签里传递资产编号，系统解析以后取得卡片ID；后续内部页面按卡片ID查询。设备名称可以相同，标签编号却应能定位到具体卡片。

这样的分工也适合产品迭代。标签尽量承担稳定识别，状态、归属、位置等会变化的信息留在系统里。调拨后不必把旧位置永远印在标签上，详情页应该反映当前记录。

## 扫码入口，为什么还保留手输编号

真实页面的入口很直接：点击扫描资产二维码，下方保留编号输入和查询。

![真实UniApp扫码入口提供扫描按钮与编号查询备用入口](https://developer.qcloudimg.com/http-save/yehe-12798805/1306aeb8e3fb78f3bea777599e421ad6.png)

*[仿真截图] 完整产品页面。测试时只替换扫码设备API的回调，不绘制假的相机画面。*

标签磨损、相机权限没有开、某个运行端暂不支持相机识别，现场仍可能需要查询资产。备用输入是另一条入口，得到结果后复用相同的编号解析与业务分流。它能帮助继续工作，但输入成功不能证明相机识别能力已经验证。

当前 `useScanCode` 把设备API封装在一个地方，业务页面取得编号后再决定做什么。最基础的解析代码如下：

```typescript
export function extractAssetCode(scanContent: string): string {
  const content = (scanContent || '').trim()
  if (!content) {
    return ''
  }
  if (!content.includes('://')) {
    return content
  }
  // 去掉 query 与 hash 后取最后一段路径
  const withoutQuery = content.split('?')[0].split('#')[0]
  const segments = withoutQuery.split('/').filter(Boolean)
  return segments.length > 0 ? segments[segments.length - 1] : ''
}
```

纯编号直接保留；带路径的短链去掉查询参数和锚点，再取最后一段。两种标签因此能复用同一业务入口。

不过，这一步只是提取候选编号。它没有完成来源域名白名单、编号格式和资产有效性验证。取出一段字符串，不代表系统里一定有这件资产，更不代表当前人可以处理它。

## 拿到编号之后，让服务端判断下一步

当前解析服务先按编号查资产卡片；没有卡片时，再查编号预分配记录。移动页面按返回状态分流。

| 返回状态 | 页面下一步 | 设计目的 |
| --- | --- | --- |
| 已建档 | 打开该资产详情 | 复用原卡，不重复建档 |
| 已预分配 | 带编号和可用预设信息进入建档页 | 让先贴标签、后补资料成为独立过程 |
| 未登记 | 提示编号无法在系统中找到 | 不把任意字符串当作新资产自动保存 |
| 已作废 | 提示编号已作废 | 避免继续使用失效编号 |

已建档分支很短：

```typescript
  if (result.scanResult === SCAN_RESULT_FILED && result.card?.id) {
    pushHistory(assetCode, result.card.assetName)
    uni.navigateTo({
      url: `/pages-asset/card/detail/index?id=${result.card.id}`,
    })
    return
  }
```

这次浏览器仿真点击了真实扫描按钮，模拟回传带查询参数的短链，页面完成编号提取、查询和详情跳转。查询响应来自教学夹具，所以它验证的是前端接线和页面呈现，没有验证真实后端的数据权限。

外部相机打开标签链接，还有登录衔接问题。当前落地页会先保留资产编号；未登录时，把当前落地路径作为登录后的回跳目标，登录以后再请求解析服务。落地页能打开，与资产明细能否读取是两个层次，后者仍应按实际账号和接口核对。

![资产编号从扫码结果经过服务端解析进入卡片或盘点任务的关系](https://developer.qcloudimg.com/http-save/yehe-12798805/af42d70e8451c5aa6502c39f039485f7.png)

*[示意图] 卡片查询与盘点提交是两条业务路径；扫码入口不会自动替用户找到并办理任意盘点任务。*

## 进入盘点任务以后，扫码会发起提交

查档案时，编号用来定位卡片；进入盘点执行页以后，同样的扫码动作承担了不同任务。

页面先加载盘点单、本人范围和明细。当前前端会在明细中寻找相同资产编号，范围外的编号提示后返回；在线模式下，范围内的编号会直接发起扫码盘点请求。

```typescript
    const updated = await scanCheckAssetStocktake({
      stocktakeId: stockId.value,
      scanContent: assetCode,
    })
    // 就地更新行，避免每扫一个都全量刷新详情
    const index = items.value.findIndex(i => i.id === updated.id)
    if (index >= 0) {
      items.value[index] = { ...items.value[index], ...updated }
    }
```

接口返回命中明细后，页面更新这一行，进度按已有结果的明细重新计算。这次使用独立的内存任务 **SIM202611050001**，回放4件教学资产；模拟返回第一件的正常结果后，页面从0/4变为1/4。

![真实UniApp盘点执行页面使用仿真响应展示一件已盘和三件待盘](https://developer.qcloudimg.com/http-save/yehe-12798805/463fff63ecb3f844fcd305ce5c46f6ed.png)

*[仿真截图] SIM任务只存在于本次教学夹具。原生完整页面截图保留全部明细，没有裁切；1/4是响应回放后的前端状态，不代表数据库已提交。*

这张图最值得注意的是“在线模式：扫一个提交一个”。在实际接入真实后端时，它不是扫码后先填一张草稿、等最后统一点保存。准备试扫时，应先确认任务、资产范围与操作身份，不能把在线识别当作完全无业务影响的预览。

服务端还会重新校验：计划是否允许盘点、该编号是否属于该计划、当前身份是否可处理对应明细。前端的范围检查改善反馈速度，服务端检查承担业务约束。当前实现对管理员模式、持执行权限的角色和普通分派人分别处理，不能拿一个权限较广的演示角色证明所有普通员工都具有相同范围。

![在线扫码从设备回调经过任务范围检查到明细返回和前端更新](https://developer.qcloudimg.com/http-save/yehe-12798805/00384248a27b42707ea4643e660e3775.png)

*[示意图] 当前在线提交路径。浏览器仿真在设备回调与HTTP响应处替换输入；真实后端检查列作源码机制。*

## 扫到标签，不等于已经确认了现场情况

系统可以知道编号存在，也可以知道这件资产属于盘点范围；设备是否真的在原位置、是否正常使用，仍需要现场判断。

当前后端的结果判定保留了一个快速路径：位置和状态都没传时，按与账面一致处理。

```java
        // 扫码盘点常见「只扫不改」：位置与状态都没填时，视为与账面一致
        if (actualLocationId == null && actualStatus == null) {
            return RESULT_NORMAL;
        }
        boolean locMatch = actualLocationId == null
                || Objects.equals(book.getExpectedLocationId(), actualLocationId);
        boolean stMatch = actualStatus == null
                || Objects.equals(book.getExpectedStatus(), actualStatus);
        return locMatch && stMatch ? RESULT_NORMAL : RESULT_ABNORMAL;
```

对于逐件找到设备、确认没有差异的场景，这能减少重复填写。代价也要理解：返回“正常”体现这条业务规则，不是相机自动确认了位置、归属和设备状态。

发现位置或状态不同，应进入明细录入相应事实；没有找到实物，也不能靠扫描照片里保存的标签把它盘成正常。

下面是10月29日AS08历史教学中的PC录入画面。案例预设第二台笔记本未找到，录入“盘亏（无实物）”，并在备注中写明教学设定及后续复核要求。

![历史教学盘点录入窗口单独填写实际位置、盘亏状态和说明](https://developer.qcloudimg.com/http-save/yehe-12798805/f2a74a8baae3ad7e2a89598bb27ce608.png)

*[历史截图] AS08真实系统教学操作，非本次模拟扫码产生；正常、盘亏和账外发现均是教学场景，不代表真实仓库损失。*

这也体现PC和移动端的分工：手机把识别和逐件处理带到现场，PC适合组织范围、分派任务、查看整体差异。二者共享编号和业务记录，不能靠把PC表格缩小就获得同样的使用体验。

## 1500ms防抖，解决的是哪一种重复

连续扫码最容易出现的问题，是同一个标签被识别两次。当前封装使用两道前端控制：`scanning` 避免一次设备回调未结束又重复唤起；上一次编号和时间用于拦截短时间同码重复。

```typescript
  function isDuplicate(assetCode: string) {
    return (
      assetCode === lastCode.value
      && Date.now() - lastScanTime.value < duplicateInterval
    )
  }
```

默认窗口为1500ms。这次直接运行现有TypeScript封装，替换设备API和时钟，完成了14项模拟检查。其中几个结果对接入最有用：

| 模拟条件 | 当前实现结果 |
| --- | --- |
| 同码间隔100ms | 返回空串并提示刚扫过 |
| 同码超过1500ms | 允许编号再次进入业务处理 |
| 立即扫描不同编号 | 允许继续 |
| 前一次扫码回调尚未结束 | 第二次调用返回空串，不再唤起设备API |
| 用户取消或设备失败 | 两者当前都按无结果返回，释放扫描状态 |
| 连续扫码回调返回false | 结束循环 |

这些检查没有测试标签可读率、真实相机速度或各端兼容性。特别是超过窗口后仍允许同码传递，说明**防抖不是后端幂等**。

当前盘点写入会累计 `checkCount`，并保留首次盘点人和时间。重复操作可以留下可回查线索，不能据此描述成“扫多少次都绝不会重复写”。返回不明时，应先查对应任务和明细，再决定是否重试。

连续扫描也并非永远自动重试。当前循环拿到空结果就退出；取消、识别失败或命中同码防抖，都可能让这次循环停止。界面需要让用户知道当前是否还在连续处理，避免误以为系统正在等待下一个标签。

## 盘点结果回到PC，继续处理差异

历史AS08教学计划最终应盘5、已盘5，正常3、盘盈1、盘亏1。下面是计数复核后的真实系统画面。

![历史教学计划在PC核对分派进度及三正常一盘盈一盘亏结果](https://developer.qcloudimg.com/http-save/yehe-12798805/6bc077c342a1fc2de68a04c3ac13270f.png)

*[历史截图] 10月29日既有教学记录。这里的5/5与前面的SIM任务1/4不是同一轮操作，不作为本次扫码写入后PC回查成功的证据。*

这组记录提醒我们，盘点完成率回答“范围内结果是否处理到位”，差异处理回答“账与物不一致怎样处置”。有了盘亏记录，仍需要按企业流程复核和处理，不能直接把盘点结果等同资产已经核销。

如果要把这套能力接入自己的业务，我会按三个层次安排：识别层专心取得稳定编号；查询层决定这个编号对应什么对象；操作层带上任务、身份和现场事实，再执行提交。把相机API、页面跳转和业务写入揉在一个按钮里，最容易让用户误判操作后果。

当前页面还保留离线暂存和同步入口，但本次没有运行离线同步与冲突恢复，不能把在线仿真扩大成完整离线验收。后续目标端验证应覆盖相机授权、断网、退出恢复、重复请求和普通员工任务范围。

一张标签能让人快速找到资产；一套可用的移动资产工具，还要让人看懂当前对象、知道自己正在查询还是提交，并在出现差异时留下可以继续处理的记录。这些细节，决定扫码入口能否真正进入日常工作。

机房里两台同型号笔记本，名字都叫“笔记本甲”，一台闲置，一台可能已经领走。拿着资产表找名称，很容易对错对象；设备上的唯一编号，才是现场和系统之间稳定的联系。

UniApp＋扫码：把资产卡片和现场盘点装进手机

用真实UniApp页面仿真扫码返回，串起资产编号解析、卡片查询和盘点任务，再拆解1500ms防抖、在线提交、任务范围与重复盘点记录。

前端

客户端

开发工具

UniApp扫码实现资产卡片与现场盘点闭环：通过解析资产编号定位设备卡片，区分查询与提交双路径，支持离线暂存、在线提交及1500ms防抖机制。仿真验证扫码回传、详情跳转、盘点进度更新全流程，覆盖正常、盘亏、账外等业务场景，实现移动端与PC端数据协同。

代码解释

TypeScript 

数据库

腾讯云双十一大促

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

UniApp＋扫码：把资产卡片和现场盘点装进手机-腾讯云开发者社区-腾讯云

UniApp＋扫码：把资产卡片和现场盘点装进手机

UniApp＋扫码：把资产卡片和现场盘点装进手机

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐