1. 定位规则不能只看条码本身#

扫码定位通常有两层匹配：

• 优先使用唯一标签，直接定位到具体对象。
• 如果没有唯一标签，再退化为按通用编码匹配。

在顺序模式下，如果同一个通用编码对应多个待处理对象，移动端要求用户扫描唯一标签是合理的。因为系统需要保证用户处理的是当前提示位置，不能随便选一个。

但在批量模式下，所有待处理对象已经同时被提示出来，用户的真实操作目标不再由“当前索引”决定，而是由“仍未完成的候选集合”决定。此时继续沿用顺序模式的严格规则，会让批量模式失去意义。

2. 批量提示不等于整批一起完成#

另一个容易忽略的点是状态清理。批量模式下，多个位置可能同时保持提示状态。用户每确认一个对象，系统只应该清理这个对象对应的局部提示状态，而不是把整批提示全部关闭。

如果确认后直接执行全量关闭，会带来两个问题：

• 用户还没处理的对象突然失去现场提示，操作体验被打断。
• 移动端本地状态和设备状态不一致，后续确认容易进入异常分支。

所以批量模式下的完成动作更像是“从活动集合里移除一个成员”，而不是“结束整个会话”。

3. 模式差异应该集中在少数决策点#

很多流程问题不是因为缺少判断，而是因为判断散落在多个方法里。今天目标定位放宽一点，明天状态清理特殊处理一下，后天硬件回调又补一个分支，最后代码会变得很难推理。

更稳妥的方式是把模式差异压缩到两个决策点：

• 扫码目标定位：同类待处理对象有多个时，批量模式可以选择一个仍未完成的候选对象。
• 完成后推进：顺序模式进入下一个对象，批量模式只清理当前对象的局部提示状态。

这样大部分校验、请求、重复扫码防护和错误反馈仍然可以复用。

移动端：先按唯一标签命中，再做模式感知降级#

扫码入口可以保持统一：先把扫码结果拆成候选 token，再从待处理集合里查找唯一标签。只有唯一标签没有命中时，才进入通用编码匹配。

1
function findScanTarget(scanCode, pendingItems, mode) {
2
  const tokens = parseScanTokens(scanCode)
3
  const byLabel = pendingItems.find(item => tokens.has(item.labelCode))
4
  if (byLabel) {
5
    return { target: byLabel }
6
  }
7

8
  const code = normalizeCommonCode(scanCode)
9
  const sameCodeItems = pendingItems.filter(item => item.commonCode === code)
10

11
  if (sameCodeItems.length === 1) {
12
    return { target: sameCodeItems[0] }
13
  }
14

15
  if (sameCodeItems.length > 1 && mode === "batch") {
16
    return { target: sameCodeItems[0] }
17
  }
18

19
  if (sameCodeItems.length > 1) {
20
    return { error: "存在多个待处理位置，请扫描唯一标签" }
21
  }
22

23
  return { error: "扫码对象不在待处理集合中" }
24
}

这里的关键不是“随便取第一个”，而是前置条件已经把集合限定在“未完成、未屏蔽、仍可处理”的范围内。批量模式允许从这个集合中取一个候选对象，是因为现场提示已经把多个位置同时暴露给用户，系统不再需要用顺序索引来约束操作。

设备联动：用局部清理替代全量关闭#

确认成功后，移动端需要根据模式决定后续动作。顺序模式通常要关闭当前提示，再切到下一项并重新亮起；批量模式则应该保留会话，只从待关闭明细中移除当前对象对应的位置。

1
async function afterConfirmSuccess(options) {
2
  if (allItemsDone()) {
3
    await turnOffAllHints()
4
    completeTask()
5
    return
6
  }
7

8
  if (options.mode === "batch") {
9
    removeConfirmedHint({
10
      groupId: options.groupId,
11
      positionId: options.positionId
12
    })
13
    return
14
  }
15

16
  await turnOffCurrentHint()
17
  moveToNextCandidate()
18
  await turnOnCurrentHint()
19
}

这个结构把“任务是否全部完成”和“当前模式如何推进”分开判断。全部完成是全局终态，任何模式都应该关闭提示并提交结束；单个对象完成只是局部状态变化，不能误当成全局结束。

状态模型：活动集合比当前索引更重要#

顺序模式下，当前索引很好用，因为页面一次只引导用户处理一个对象。但批量模式下，当前索引只能作为展示辅助，不能作为业务真相。真正可靠的状态应该是几个集合：

• 待处理集合：还没有确认完成的对象。
• 活动提示集合：当前仍保持现场提示的对象。
• 已处理集合：已经完成确认，且不应再接受重复扫码的对象。

可以用一个简单流程表示：

1
flowchart LR
2
  Scan["扫码输入"] --> Match["从待处理集合定位目标"]
3
  Match --> Request["提交确认请求"]
4
  Request --> Success["确认成功"]
5
  Success --> Done{"是否全部完成"}
6
  Done -->|是| CloseAll["关闭全部提示并结束任务"]
7
  Done -->|否，顺序模式| Next["关闭当前提示并推进下一项"]
8
  Done -->|否，批量模式| RemoveOne["移除当前对象的提示状态"]

当页面以集合为中心建模时，模式差异会自然落在集合操作上：顺序模式移动游标，批量模式删除成员，终态流程清空集合。

1. 把顺序模式的约束带到批量模式#

顺序模式强调“当前对象”，批量模式强调“候选集合”。如果批量模式仍然要求用户在同类对象中扫描唯一标签，系统就没有真正支持批量操作，只是一次性把多个提示打开了而已。

2. 单个确认后关闭整批提示#

批量提示的会话生命周期通常长于单个对象。确认一个对象后，应该只清理它对应的提示明细；等全部对象都完成后，再进入全量关闭和任务完成逻辑。

3. 只改前端定位，不改完成推进#

如果只放开扫码定位，不调整确认后的状态清理，就会出现“能扫进来，但扫完后现场提示乱掉”的问题。扫码策略和提示状态必须一起设计。

4. 用页面展示顺序代替后端确认结果#

实际确认对象最好以后端返回为准。移动端可以先用本地集合做候选定位，但最终标记完成、清理提示时，应优先使用接口返回的对象和位置信息，避免弱网、缓存或列表重排造成错位。