门店端 SDK 解决的是「用一台手持终端在现场完成判定」的问题。它把扫码录入、目录查询、件号对照与结果留痕这几类能力收在一层,让调用方不必自己处理与后端数据版本的衔接细节;因此判断该不该用它,看的不是功能列表有多长,而是目标车系与目标系统版本是否落在它覆盖的组合里。
接入前的核对顺序通常是:先确定要覆盖的产品大类,再确定该大类在当前目录版本上开放了哪些字段,最后确认移动端系统版本与依赖库仍被支持。跳过中间一步是做这类集成最常见的返工原因——同一系列的新车型往往比旧车型多出若干条适配关系,把它当成同一套代码去复用就会在实车上失败。
能力是否可用与账号是否被授权是两件事。前者由目录与数据版本决定,后者由申请与审核决定,两者混在一起会让人以为接口坏了。排障时先确认数据侧支持,再确认授权状态,最后才怀疑调用方式,这个顺序能省掉大量无效试验。
按能力分组
- 扫码与录入
- 目录与件号对照
- 适配关系查询
- 工单与留痕
- 数据版本核对
接入前确认
- 目标产品大类
- 当前目录版本
- 移动端系统版本
- 依赖库是否仍被支持
- 账号授权范围
文档类型
- 接口说明
- 集成指引
- 示例工程
- 常见问题
- 变更记录
云端适配服务 API
把适配数据接到自有服务侧的另一条技术路线。
服务与支持
授权与设备状态查不清时的人工渠道入口。
先定设备再谈接口
同一句调用在不同年款的车系上支持度不同。把目标车型写进设计文档,比把接口背下来更有用。
能力与授权分开排查
支持但没授权,看起来像不支持。两步拆开,返工量立刻下降。
不抄版本号
版本兼容关系由当期文档规定。
真机优先于模拟器
扫码与对照的失败大多只在真实门店环境出现。把实车核对排在流程早期,而不是留到上线前最后一晚。