Java 17 视觉识别结果的金额与字段门禁实现
内容提要
文章介绍用Java 17为视觉识别票据金额设置安全门禁：模型只负责提取字段，Java用BigDecimal、币种白名单和金额上限判断能否进入人工复核，避免浮点误差与误报销。代码无需外部依赖，并强调超时、幂等、原图留存与审计，适合低风险票据预分流，不适用于自动付款或税务认定。
延伸解读
为什么用 BigDecimal 而不是 double
文章强调货币比较必须避免二进制浮点误差，因此用 BigDecimal 解析模型返回的金额字符串。double 在表示 0.1 等十进制小数时存在精度问题，可能导致 128.50 与 128.5 比较异常或边界判断出错。BigDecimal 的 compareTo 能按数值精确比较，配合 signum 检查正负，适合作为金额门禁的基础。
模型输出不可直接信任的常见场景
文章列举了几类失败：图片模糊导致小数点错位，模型可能返回带货币符号的“￥128.5”而非纯数字，以及请求超时或限流。应对方式是要求结构化数字字段，解析失败时直接拒绝；设置连接超时 10 秒、请求超时 20 秒；重试前检查请求是否已入队，避免重复处理。
幂等与审计是生产化的必要补充
文章指出同一票据重复提交是现实风险，建议以图片哈希和发票号作为幂等键。此外，工程化还应增加版式置信度、原图授权与保存期限、审计记录及人工纠错回流。这些措施不改变门禁的核心逻辑，但能保证系统在真实业务中可追溯、可复核，而不是只依赖一次模型输出。
适用边界：预分流而非自动付款
文章明确该方案适合低风险票据预分流，即用 Java 门禁决定能否进入人工复核，不适合自动付款、税务认定或伪造判断。币种白名单和金额上限只是第一道过滤，最终仍需人工确认。读者应避免把识别结果直接用于报销或付款，以免因模型误判造成财务风险。
Q&A
为什么处理视觉识别出的票据金额时要用 BigDecimal 而不是 double？
因为货币比较需要避免二进制浮点误差，使用 BigDecimal 可以精确表示和比较金额，防止因浮点误差导致误判。
Java 门禁中如何判断识别出的金额能否进入人工复核？
门禁会检查商户是否为空、币种是否在白名单内、金额是否大于零且不超过上限（如 1000.00），全部通过才返回进入人工复核。
视觉识别票据金额时常见的失败情况有哪些？
常见失败包括：图片不清导致小数点错位、模型返回带符号的金额（如“￥128.5”）、请求超时或限流、同一票据重复提交。
如何防止同一张票据被重复提交报销？
生产环境中可以使用图片哈希和发票号作为幂等键，确保同一票据只被处理一次。
这个金额门禁方案适合哪些场景，不适合哪些场景？
适合低风险票据预分流，不适合自动付款、税务认定或伪造判断。
在工程化落地时还需要增加哪些措施？
需要增加版式置信度、原图授权与保存期限、审计记录及人工纠错回流。
