2026 年 11 月 2 日，讯果上线礼品卡批量查询的结果治理能力。此前客户端负责把卡号查出来，查询之后的去重、归类与对账仍要靠人工在表格里做；新版本把这三步收进结果页：卡号先做标准化，再按指纹剔除重复项，最后把每条记录归入七类状态之一，并给出处置建议。在 12,480 张卡的真实样本中，重复项占 3.7%，核对耗时从人工的 96 分钟缩短到 9 分钟。
做这件事的动因来自对账环节。礼品卡业务里最麻烦的不是查不到余额，而是查完之后数据不干净：同一张卡在几个批次的清单里各出现一次，卡号中间多了一个空格就被当成两张不同的卡，导出之后财务按数量核算，一对就差了两位数。数据产品经理郑楠在需求评审时说：“查询本身已经是秒级了，真正占时间的是把结果整理成能核对的样子。”
重复项从哪里来
样本里的 462 条重复记录可以分成三类。最大的一类是同卡不同写法，占 318 条：卡号中间带连字符、首尾有空格、全角数字与半角数字混用、字母大小写不一致。这些写法在程序看来是完全不同的字符串，但指向同一张卡。第二类是跨批次重复，占 112 条：运营按月导出清单时没有剔除上月已经查询过的卡，叠加到新清单里。第三类是表格合并造成的整行重复，占 32 条。
这三类问题都不是操作者粗心。清单来自不同渠道，格式本来就五花八门；团队里几个人各自维护一份表，合并时很难逐一比对。旧版本的结果页会忠实地把每一条都列出来，看起来条目齐全，实际数量是虚高的。
卡号标准化与指纹去重
去重的前提是先把卡号写成同一种形式。客户端会去掉所有空白与连字符，把全角字符转成半角，字母统一为大写，再校验位数与校验位；校验不通过的记录不会进入去重环节，而是直接归入“格式错误”。这一步把 318 条不同写法收敛成了同一批卡号。
标准化之后计算指纹：把卡号、面额与地区码三者拼接后做一次 SHA-256，取结果作为唯一标识。查询队列按指纹去重，同一指纹只查一次；结果页保留首次出现的记录作为主记录，其余标记为重复项并注明重复来源批次，导出时默认折叠但仍可展开查看。指纹只存在本地结果库里，原始卡号按站点既有的本地加密方案存储，不上传任何服务端。
有一个边界情况需要说明：同一卡号出现在两个不同面额的清单里，指纹不同，不会被自动合并。这类记录会被额外打上冲突标记，归入“待人工复核”，避免因为猜测面额而把可用的卡误判成重复。测试组用 600 张卡做人工抽样比对，去重结果与人工判断一致，没有出现误删。
七类状态与处置建议
归类规则按优先级从高到低执行，一条记录只落在一个状态里。格式错误与重复项优先判定，因为它们不需要发起查询；其余五类在查询完成后按返回结果判定。每一类状态在界面上都配一句处置建议，导出时同样写入状态说明列，方便交给不熟悉工具的同事。
| 状态 | 判定依据 | 建议处置 |
|---|---|---|
| 有效可用 | 查询成功、余额大于 0 且未标记已兑换 | 进入可用库存，按面额归集 |
| 已兑换 | 余额归零或返回已使用 | 从库存剔除，保留记录备查 |
| 余额不足 | 余额低于设定的提醒阈值 | 单独列出，按业务规则决定是否合并使用 |
| 格式错误 | 位数不符或校验位不通过，未发起查询 | 回到原始清单修正后重导 |
| 重复项 | 指纹命中已有记录 | 默认折叠，保留来源批次以便追溯 |
| 待人工复核 | 同卡不同面额、跨地区冲突 | 人工确认面额与归属后再合并 |
| 查询失败 | 网络错误或服务端异常，未取得结论 | 按线路状态重试，不计入失败率的分母 |
把“查询失败”与“余额不足”分开统计，是对账时最常被忽略的一点。失败代表没有结论，重试之后可能变成有效卡；如果有团队把两者合并写成“异常”，账面数量就会偏小，月底核对时反复解释。新版本在汇总卡片上分别给出两类数量，并在导出文件的表头注明统计口径。
实测数据与落地建议
实测样本为 12,480 张卡，来自三个业务团队的六个批次。去重后实际发起查询 12,018 张，剔除重复项 462 张。状态分布为：有效可用 8,946 张（74.4%）、已兑换 1,236 张、余额不足 704 张、格式错误 512 张、待人工复核 186 张、查询失败 434 张。格式错误的 512 条里，有 449 条是位数不足的录入错误，集中在同一份手工清单。
耗时方面，去重与归类在本地完成，12,480 条记录的处理用时 11 秒；人工用表格工具完成同样的工作（含格式统一、重复项比对、状态拆分）平均 96 分钟，且在不同人手里结果不一致。查询本身的耗时不受影响，仍按既有的并发档位与线路调度执行。
- 先用 500 张左右的小批样本校准余额提醒阈值，阈值不同会直接影响“余额不足”的数量
- 导出时保留原始行号，重复项折叠后仍可定位到清单里的具体位置
- 待人工复核的条目建议当天处理完毕，跨天之后很难回忆起当时的面额来源
- 月度对账前先跑一次全量去重，再按状态导出，避免把重复项计入发放数量
结果治理与已有的工作流、加密存储是配套关系。去重与归类可以作为一个动作插进工作流的核验之前，先清洗再查询，能减少无谓的请求量；处理过程产生的临时结果同样走本地加密，退出登录后自动清理解密缓存。需要了解查询侧的性能与加密细节，可以查看吞吐扩容与本地加密加固两篇说明。
本次能力随 v5.2.1 推送，已安装用户更新后即可在结果页看到“去重与归类”入口，历史结果可以在本地重新跑一次归类，不会重新发起查询。建议第一次使用时保留旧结果做对照，确认状态分布与人工判断一致后，再把它纳入日常对账流程。
用户评论（5）
去重之后数量少了四百多张，一开始以为漏了，展开重复项能看到每一条的来源批次，核对完就放心了。
格式错误和查询失败分开统计这点很关键，以前月底对账总要跟财务解释一遍“异常”里到底包含什么。
我们清单里全角数字比较多，标准化之后重复项一下就现形了，这部分以前完全看不出来。
待人工复核的 186 条当天处理完了，主要是同卡不同面额，确认后再合并，没有误伤可用的卡。
去重和归类放在本地跑，十几秒结束，卡号没出过本机，这点符合我们的合规要求。