车架号 API 接入后，要依次判断 HTTP、业务 status 和车型结果。极速车服 VIN 接口可能返回多个候选，不能把请求成功或 carlist 第一条直接当成最终车型。

VIN 接口解决哪一步？

VIN 是车辆识别入口。极速车服（jisuepc）的 VIN 车辆识别代码查询 API 当前公开接口地址为 https://api.jisuepc.com/vin/query，支持 GET、POST，请求参数包括必填 vin，以及可选的 caridtype 和 strict。接口返回车辆基础字段，并将一对多候选放在 carlist 中。

carlist 中可见 carid、name、typeid、typename 和 model 等字段。它解决的是车辆识别和候选收敛，不是最终配件适配或采购保证。年款、动力、变速箱、配置、生产批次和替换关系仍可能改变查件结果。

接入前应准备什么？

前端可以收集 VIN，但 APPKEY 和请求逻辑应放在服务端。建议把下列信息分层保存：

数据层 建议保留的信息 作用
输入层 脱敏后的 VIN 标识、请求时间、业务单号 回查请求和避免重复调用
鉴权层 服务端环境变量中的 APPKEY 避免密钥进入前端、仓库和公开日志
结果层 原始 carlist、车型字段、确认状态、选中的 carid 连接车型确认和后续 EPC 查件

完整 VIN 是否需要长期保存，应按业务目的和适用规则决定；普通访问日志通常只需保留任务编号、脱敏标识和结果摘要。

官方请求怎样写成安全模板？

下面使用官方当前地址和参数名，仅作为联调模板，不会自动发起请求，也不代表某个 VIN 已经查到结果：

curl --request POST "https://api.jisuepc.com/vin/query" \
  --data-urlencode "appkey=YOUR_APPKEY" \
  --data-urlencode "vin=YOUR_VIN" \
  --data-urlencode "strict=0"

strict 在文档中表示是否严格校验 VIN，取值为 0 或 1，默认值为 0。它是请求参数，不是车型已确认的业务结论。若使用 GET，应注意查询字符串可能被代理、浏览器历史或访问日志记录，生产系统应按自身网关策略评估日志脱敏。

程序应该怎样判断返回？

建议按以下顺序处理，不要只判断“有没有 JSON”：

  1. HTTP 层。 记录超时、连接失败和非预期 HTTP 状态，进入网络或上游异常处理。
  2. 解析层。 响应不是合法 JSON 时保留请求编号和错误类别，不把原始密钥或完整响应直接写入日志。
  3. 业务层。 按官方 status 和 msg 判断。当前页面列出的接口错误包括 201（VIN 为空）、202（VIN 不正确）和 210（没有信息）；系统错误还包括 APPKEY、权限、次数、IP 和接口维护等状态。
  4. 车型层。 业务成功后读取 carlist 和候选字段；保留全部候选，按年款、发动机、变速箱、车身和现车资料确认 carid。
  5. 后续层。 只有车型确认后，才把 carid 传给 EPC 或零件查询；候选冲突时进入补充资料或人工复核。

业务系统可以设置 vehicle_pending、vehicle_confirmed 和 manual_review 等状态名，但它们不是极速车服接口返回字段。

空结果能直接说明 VIN 无效吗？

不能。空结果可能来自输入被截断、参数或 APPKEY 配置错误、权限或次数状态，也可能是当前查询没有信息。先核对请求地址和参数，再区分 HTTP、系统错误和接口错误；不要把所有失败都改写成“车辆不存在”。

需要查看错误码、参数和动态计费规则时，应回到 VIN API 当前详情页。本文没有使用真实 VIN 发起计费请求。

总结

车架号 API 的可维护接入方式是“服务端请求、分层判断、保留 carlist、确认车型、再进入 EPC”。HTTP 成功只是网络层结果，status=0 也只是接口业务成功；只有完成车型确认，后续配件结果才有继续核验的基础。

标签：