覆盖范围、依赖前提与自查清单

门店端适配 SDK

门店端 SDK 解决的是「用一台手持终端在现场完成判定」的问题。它把扫码录入、目录查询、件号对照与结果留痕这几类能力收在一层,让调用方不必自己处理与后端数据版本的衔接细节;因此判断该不该用它,看的不是功能列表有多长,而是目标车系与目标系统版本是否落在它覆盖的组合里。

接入前的核对顺序通常是:先确定要覆盖的产品大类,再确定该大类在当前目录版本上开放了哪些字段,最后确认移动端系统版本与依赖库仍被支持。跳过中间一步是做这类集成最常见的返工原因——同一系列的新车型往往比旧车型多出若干条适配关系,把它当成同一套代码去复用就会在实车上失败。

能力是否可用与账号是否被授权是两件事。前者由目录与数据版本决定,后者由申请与审核决定,两者混在一起会让人以为接口坏了。排障时先确认数据侧支持,再确认授权状态,最后才怀疑调用方式,这个顺序能省掉大量无效试验。

按能力分组

  • 扫码与录入
  • 目录与件号对照
  • 适配关系查询
  • 工单与留痕
  • 数据版本核对

接入前确认

  • 目标产品大类
  • 当前目录版本
  • 移动端系统版本
  • 依赖库是否仍被支持
  • 账号授权范围

文档类型

  • 接口说明
  • 集成指引
  • 示例工程
  • 常见问题
  • 变更记录

安全响应

发现接口层面的安全隐患时的报告通道说明。

服务与支持

授权与设备状态查不清时的人工渠道入口。

先定设备再谈接口

同一句调用在不同年款的车系上支持度不同。把目标车型写进设计文档,比把接口背下来更有用。

能力与授权分开排查

支持但没授权,看起来像不支持。两步拆开,返工量立刻下降。

不抄版本号

版本兼容关系由当期文档规定。

真机优先于模拟器

扫码与对照的失败大多只在真实门店环境出现。把实车核对排在流程早期,而不是留到上线前最后一晚。