说明：本文的 ThresholdBench、任务 TB-1606、文档 DOC-07、示例置信度和 HiLog 都是为解释状态机而设计的受控演示数据；配图是独立绘制的 DevEco/手机界面示意，不是真实编译、真机运行或 OCR 服务评测结果。代码应在项目采用的 SDK 与设备上重新编译、联调。

一、阈值往上拖，为什么不该立刻算成一笔配置修改

做 OCR 质检页面时，一个容易被轻描淡写的交互是“把低置信度阈值从 70 调到 75”。从界面看，无非一个滑块、一行待复核数量。但只要把它接到批量校对流程上，就会出现两个不同含义：手指滑动时，人想试探筛查范围；点击确认后，人才真正接受这次策略变化。把这两个动作都写到同一个变量里，后面的批次审核、历史回显、撤销操作就无法判断当前看到的是预览还是正式值。

我把这个问题缩到一个名为 ThresholdBench 的单页 Demo，页面叫 ReviewThresholdPage，示例任务 TB-1606，文档 DOC-07。这里没有调用 OCR 引擎，输入是一组固定的 12 行置信度：92、68、86、59、74、96、83、62、88、71、90、77。正式阈值是 70，界面上正在预览的草稿阈值是 75；按照“严格小于阈值就加入人工复核队列”的规则，75 对应 5 行待复核。数值是演示样本，不代表任何真实识别准确率。

我更在意的是阈值背后的责任边界。用户拖到 75 后退出页面，产品究竟应该保留 70 还是 75？如果没有确认按钮，答案并不明确。当前设计明确规定：savedThreshold 只代表已确认值，draftThreshold 只代表本次界面试探，pendingCount 是依草稿临时计算的投影，状态文本只有“待提交”“确认中”“已确认”三类。页面关闭时未提交的草稿直接丢弃，重新进入则用已经保存的业务配置初始化。实际项目若要跨进程持久化，再由独立仓储层处理，不让 Slider 事件直接承担落盘职责。

封面中的滑块是这个工程问题的视觉提示，并非已经跑通 OCR 识别的截图。技术方向落在 ArkUI 的 Slider 事件语义和业务状态分层，而不是模型本身。

二、把“预览”做成纯计算，而不是边拖边请求

第一段代码先把业务输入固定下来。缺测值、无穷大、负值或超过 100 的置信度都不应混进合格统计。界面里的 75 也不能只是一个看着正确、实际未经规整的浮点数：我们约定以 5 为步长，提交前再执行一次钳制。待复核采用 < 而非 <=，这样 75 分恰好在阈值上时仍保留在普通列表，验收时不会因为边界取值含糊而出现一条差异。

interface OcrLine {
  id: string;
  confidence: number;
}

const DEMO_ROWS: OcrLine[] = [
  { id: 'L01', confidence: 92 }, { id: 'L02', confidence: 68 },
  { id: 'L03', confidence: 86 }, { id: 'L04', confidence: 59 },
  { id: 'L05', confidence: 74 }, { id: 'L06', confidence: 96 },
  { id: 'L07', confidence: 83 }, { id: 'L08', confidence: 62 },
  { id: 'L09', confidence: 88 }, { id: 'L10', confidence: 71 },
  { id: 'L11', confidence: 90 }, { id: 'L12', confidence: 77 }
];

function safeThreshold(value: number): number {
  if (!Number.isFinite(value)) return 70;
  return Math.max(0, Math.min(100, Math.round(value / 5) * 5));
}

function countPending(rows: OcrLine[], threshold: number): number {
  return rows.filter((row: OcrLine) =>
    Number.isFinite(row.confidence) &&
    row.confidence >= 0 && row.confidence <= 100 &&
    row.confidence < threshold
  ).length;
}

这里返回的只是 UI 所需的整数，不对行对象排序，也不改变它们的原始置信度。坏数据被排除，不意味着可以假装它已经识别成功；真正的导出或复核服务应将无效行单独计入异常队列。示例数组存在模块内，离开页面不需要关闭文件句柄或网络连接，但如果真实项目将其换成订阅的数据源，应在页面消失时取消订阅，不要依靠一次性的 Demo 数据结构推断生产环境的生命周期。

三、Slider 的 Moving 和 End，不是同一个业务事件

第二段代码是页面的核心。华为文档给 Slider 提供了 value/min/max/step，onChange 回调中还能拿到 SliderChangeMode；其中 Moving 表示拖动中的值变化，End 表示交互结束。这里不把 End 解读为“用户批准保存”。手指离开滑块，只说明交互完成；是否采用新阈值，仍要通过显式确认表达。这样即使用户在滑动时看见“5 行待复核”，正式配置也不会悄悄改变。

@Entry
@Component
struct ReviewThresholdPage {
  @State savedThreshold: number = 70;
  @State draftThreshold: number = 75;
  @State pendingCount: number = 5;
  @State status: string = '待提交';
  private ticket: number = 0;

  private preview(value: number): void {
    this.ticket += 1; // 使尚未完成的旧确认回执失效
    this.draftThreshold = safeThreshold(value);
    this.pendingCount = countPending(DEMO_ROWS, this.draftThreshold);
    this.status = this.draftThreshold === this.savedThreshold
      ? '已确认' : '待提交';
  }

  build() {
    Column({ space: 18 }) {
      Text('ThresholdBench · TB-1606').fontSize(22)
      Text('DOC-07 | 数据版本 v4')
      Text(`正式阈值 ${this.savedThreshold}  /  预览 ${this.draftThreshold}`)
      Slider({ value: this.draftThreshold, min: 0, max: 100, step: 5 })
        .onChange((value: number, mode: SliderChangeMode) => {
          if (mode === SliderChangeMode.Moving ||
              mode === SliderChangeMode.End ||
              mode === SliderChangeMode.Click) this.preview(value);
        })
      Text(`待复核 ${this.pendingCount} / 12 行`)
      Text(this.status)
      Button('确认本次阈值').onClick(() => { this.confirm(); })
    }.padding(20).width('100%')
  }
}

这里直接在草稿变化时计算 12 行的筛查数量，没有使用定时器，也没有把每一帧手势都发往后端。对于几千行、几万行的数据集，应改成索引结构、后台计算或节流投影；但优化之前需要先确立两个变量的含义，否则只会更快地制造错误。Slider 的触摸开始或结束属于组件交互语义；savedThreshold 的改变则是应用层行为，两个层次不能混用。

DevEco 示意图刻意把工程目录、ReviewThresholdPage.ets、右侧模拟器和底部 HiLog 分开。图中 TB-1606、DOC-07、70/75、5/12 与正文一致；日志文字也是演示构造的期望输出，不是实际采集的性能证据。

四、确认按钮要提交快照，不能提交一个不断变化的引用

确认按钮看起来只需要一次赋值，但真实业务一般要等仓储层或者接口回执。如果点击确认后，用户继续把阈值拖回 65，旧确认异步返回时仍写入 75，就会出现“界面已经预览另一个值，正式配置却在后台改掉”的错乱。因此第三段代码给每次草稿变化一个单调递增的 ticket。真正的持久化接口尚未接入；这里用 Promise.resolve() 构造可读的异步边界演示，并不暗示已经完成服务端保存。

// 放在 ReviewThresholdPage 组件内
private async confirm(): Promise<void> {
  if (this.status === '确认中') return;
  const currentTicket: number = ++this.ticket;
  const snapshot: number = safeThreshold(this.draftThreshold);
  this.status = '确认中';

  try {
    await Promise.resolve(); // 仅演示异步回执，不是落盘/网络调用
    if (currentTicket !== this.ticket) return;
    this.savedThreshold = snapshot;
    this.status = '已确认';
  } catch (_) {
    if (currentTicket === this.ticket) this.status = '待提交';
  }
}

ticket 仅在当前组件实例内生效，不能当成分布式版本号，更不是事务 ID。生产系统应该连同 DOC-07、数据版本 v4、操作者上下文一起传给仓储或服务端，由服务端独立校验权限与版本冲突。try/catch 只处理提交路径本身的异常，不能吞掉版本不一致后的用户反馈；旧回执被忽略时应按真实产品需求提示“本次配置已变更，请重新确认”。

五、怎样检查“手指松开后仍未保存”这个边界

我给这页设计了五条可以手工检查的验收动作。先以已确认 70 进入页面，筛查集合应是低于 70 的 68、59、62 三行。然后拖到 75，预览集合增加 74、71，界面出现 5/12，但正式值仍显示 70，状态是“待提交”。第三步不点确认就返回页面，再进入时应按正式设置回到 70，而不是从上一轮未完成操作恢复 75。第四步点击确认后，只在有效回执到达时正式值才变成 75。第五步要在确认仍挂起时继续拖动：旧票据不能覆盖新草稿。

这些属于预期验收步骤，而不是本次已经执行并通过的真机测试。若 Slider 接了无障碍步长、键盘或外部设置同步，还要补测非触摸输入；如果新的配置来自其他设备，组件本地 ticket 不足以决定胜负，必须引入业务修订号。还有一个细节：Moving 可能在一次拖动期间多次回调，日志不应该逐帧写到线上监控，更不应该让每次事件都造成落盘，以免制造大量无意义 IO。

纯屏幕示意在顶部保留 10:24、5G、Wi-Fi、信号条和电量 86%，屏幕中间固定显示 ThresholdBench、TB-1606、DOC-07、正式 70、预览 75、待复核 5/12、待提交。图片是给读者复核状态含义的辅助证据，而不是模拟器或设备真实画面。

六、收尾：输入控件不用负责替业务做决定

这次拆开的并不只是两个数字，而是用户试探、可见预览、显式确认、正式版本四个相互关联又不等价的阶段。给他们各自命名后，异常处理就有了落点：无效分数不污染筛查、滑动回调不触发提交、并发回执不反写新草稿、页面退出不私自保存。对于 OCR、图像超分参数、分类门槛等具有“预览后才决定”特征的场景，这个小模式都值得保留。

本例真正有把握的结论是状态设计，而不是任何 OCR 准确率或运行性能。生产落地前还要补齐真实 OCR 行数据映射、持久化仓储、权限、可访问性、错误提示以及对应 SDK 编译和设备验收。参考：华为官方 Slider API（https://developer.huawei.com/consumer/en/doc/harmonyos-references-V14/ts-basic-components-slider-V14）以及 ArkTS 基础语言介绍（https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/introduction-to-arkts）。