发票查验页面需在3秒内完成真伪确认、异常定位与归档，须严格遵循税务总局接口规范，防御性取值、精准校验输入、区分业务态渲染结果，并提供一键复制与原生PDF导出功能。
发票查验页面不是“展示数据就行”，核心是让用户在3秒内确认真伪、定位异常、完成归档。直接套用通用表格组件或手写一堆 div 堆叠，90% 会在税务平台对接、OCR识别结果渲染、防重复提交这三处翻车。
发票查验接口返回结构必须提前对齐
国家税务总局增值税发票查验平台（https://inv-veri.chinatax.gov.cn）返回的 JSON 是强约束格式，字段名、嵌套层级、空值处理都固定。前端若按自己臆想的结构写 response.data.invoiceNo，实际返回却是 response.result.fpdm（发票代码）、response.result.fphm（发票号码），必然报 Cannot read property 'fpdm' of undefined。
- 务必以官方文档为准：查验接口返回字段含
fpdm（发票代码）、fphm（发票号码）、kprq（开票日期，格式为yyyyMMdd）、jym（校验码后6位）、result（true/false）、message（提示文字） - 后端代理层建议做字段映射，但前端仍需防御性取值：
data?.result?.fpdm || data?.fpdm，避免因响应结构微调导致白屏 - 日期字段不能直接
new Date(kprq)—— 它是字符串，需手动转为YYYY-MM-DD格式再渲染，否则 Chrome 可能解析失败
input 输入框必须限制发票代码/号码长度与字符集
发票代码固定12位，发票号码固定8位，且均为纯数字。放任用户自由输入会导致大量无效请求、触发查验平台频率限制，甚至被判定为恶意探测。
- 用
maxlength="12"+pattern="[0-9]{12}"硬性约束发票代码；同理，号码用maxlength="8"+pattern="[0-9]{8}" - 配合
oninput实时过滤非数字字符：this.value = this.value.replace(/[^0-9]/g, '')，比仅靠pattern更可靠 - 校验码后6位（
jym）允许大小写字母+数字，但长度严格为6，应设pattern="[0-9A-Za-z]{6}"，不可用type="number"（会拒收字母）
查验结果渲染要区分“业务态”和“技术态”
财务人员不关心 HTTP 状态码或 JSON key 名，只看“是不是真的”“哪里不对”。把 message: "发票代码、号码不一致" 直接扔给用户，等于没查。
立即学习“前端免费学习笔记（深入）”；
- 真票且信息完整 → 显示绿色对勾 + “查验通过”，高亮显示销售方名称、金额、开票日期
- 查无此票 / 代码号码错 → 明确提示“未查询到该发票信息，请核对发票代码、号码、日期是否正确”，并自动聚焦到第一个出错输入框
- 状态异常（如已作废、已红冲）→ 用橙色警示框，文案为“该发票状态：已作废”，并附带税务局原文
message做小字备注 - 绝对禁止显示原始
response对象或控制台日志 —— 这属于敏感调试信息，有合规风险
页面必须内置“一键复制查验结果”与“导出为PDF”逻辑
查验完不是终点，用户下一步大概率是截图发给财务、存档或粘贴进报销系统。手动选中、右键、截图、裁剪……每一步都在增加出错概率。
- “复制结果”按钮背后调用
navigator.clipboard.writeText()，内容组织为纯文本块：发票代码：123456789012\n发票号码：87654321\n开票日期：2026-05-20\n销售方：XX科技有限公司\n金额：¥12,800.00\n查验结果：通过 - “导出PDF”不要依赖第三方库（如 jsPDF + html2canvas 组合易失真），优先用浏览器原生
window.print()配合@media print样式：隐藏按钮、背景图、非关键元素，固定字体为"SimSun", "KaiTi"，确保打印/另存为 PDF 时格式不崩 - 导出前检查是否已查验成功 —— 若未查就点导出，生成空白 PDF 是最常被投诉的问题
最容易被忽略的是时间戳精度：开票日期 kprq 是精确到日的字符串，但很多系统会把它当成时间戳参与计算，导致跨月查验时误判“过期”。它只是个标识字段，别拿它做 Date.now() - kprq 类运算。
