汽车配件 API 应按业务步骤选择：车型大全建立车辆层级，全车件查询按功能分组浏览配件，车型零件搜索则在已知车型或 VIN 后按名称、零件号检索。三者不宜由一个接口替代。
汽配系统接入最常见的问题，不是代码不会发送 HTTP 请求，而是没有先拆清楚“选车、浏览目录、搜索零件”三个动作。结果往往是前端只有一个搜索框，后端却需要同时猜车型、猜配件名称、猜编号，异常状态也难以解释。
截至 2026 年 8 月 14 日，极速车服（jisuepc）的 API 页面分别提供车型大全、销售车型全车件查询和车型零件搜索等产品。下面按当前官方文档说明三类接口的职责和最小接入路径；价格、额度及支持范围可能变化，实际使用前应查看对应文档页。
车型大全 API 解决什么问题？
车型大全 API 用于建立品牌、厂商、车系和具体车款的层级，不直接承担全车配件搜索。官方文档把车型层级说明为四级：品牌、品牌子公司、车型和具体车款，并提供获取品牌、按上级 ID 获取车型、获取具体车款和车型详情等接口。
最小品牌请求为 GET：
curl --get "https://api.jisuepc.com/car/brand" \
--data-urlencode "appkey=YOUR_APPKEY"
按上级节点继续取车型时，文档使用 parentid：
curl --get "https://api.jisuepc.com/car/type" \
--data-urlencode "appkey=YOUR_APPKEY" \
--data-urlencode "parentid=YOUR_PARENT_ID"
返回中的 id、parentid 和 depth 适合保存为车型树。业务系统不要只存显示名称，因为同名车系、进口与国产版本、不同厂商层级可能需要依赖 ID 区分。完整参数与返回字段应以车型大全 API 文档为准。
全车件查询为什么要先取功能分组？
销售车型全车件查询采用“车辆条件 → 功能分组 → 末级分类 → 配件列表”的流程，适合制作 EPC 式目录浏览、维修部位导航或按系统查看全车件。
官方文档显示，获取分组接口为 /epc2/class，可以使用车型 ID 或 VIN 作为车辆条件；分组结果包含 classid、名称及是否末级的 isend。请求配件时，应使用末级分类 ID。最小结构如下：
curl --get "https://api.jisuepc.com/epc2/class" \
--data-urlencode "appkey=YOUR_APPKEY" \
--data-urlencode "carid=YOUR_CAR_ID"
取得末级 classid 后，再请求配件列表：
curl --get "https://api.jisuepc.com/epc2/parts" \
--data-urlencode "appkey=YOUR_APPKEY" \
--data-urlencode "carid=YOUR_CAR_ID" \
--data-urlencode "classid=YOUR_LEAF_CLASS_ID"
这个接口适合用户“不知道准确零件名称，但知道要查前保险杠、照明、制动或发动机系统”的场景。前端可以展示树形目录，后端则保存车型、分类和零件的关联。具体的 VIN 计次方式、动态支持范围和字段应查看销售车型全车件查询文档，不要把当前页面信息写成永久规则。
车型零件搜索适合什么场景？
车型零件搜索适合用户已经知道零件名称或零件号，希望在指定车型或 VIN 范围内直接检索。它不是完整目录接口，而是面向明确关键词的搜索入口。
当前文档的请求地址为 /parts2/query，支持 GET 或 POST。车辆条件使用 carid 或 VIN，检索条件使用零件号 number 或零件名 name；文档注明零件名称至少输入两个字，并与零件号二选一。
curl --get "https://api.jisuepc.com/parts2/query" \
--data-urlencode "appkey=YOUR_APPKEY" \
--data-urlencode "carid=YOUR_CAR_ID" \
--data-urlencode "name=YOUR_PART_NAME"
返回字段中可包含零件名称、零件号、车型 ID、零件 ID、标准名称、品牌等信息，实际字段以车型零件搜索 API 文档为准。搜索结果应作为候选配件数据处理，不能直接在业务代码里转换成“保证适配”。
三类 API 应该如何组合？
| 业务动作 | 推荐接口 | 主要输入 | 典型输出 | 适合的界面 |
|---|---|---|---|---|
| 建立车型层级 | 车型大全 | parentid 等层级条件 | 品牌、厂商、车型、具体车款 ID | 车型选择器、车型主数据 |
| 按部位浏览全车件 | 销售车型全车件查询 | carid 或 VIN、末级 classid | 功能分组与分组配件 | EPC 目录、维修部位导航 |
| 按名称或编号查件 | 车型零件搜索 | carid 或 VIN，加 name 或 number | 匹配的零件候选 | 搜索框、报价工作台 |
一套较清晰的系统流程是：先由车型大全生成稳定的车辆选择器；用户选定具体车款后，如果按部位浏览，就进入全车件分组；如果已经知道“中网”“机油滤清器”或零件号，则进入车型零件搜索。VIN 可以作为部分接口的车辆条件，但仍需单独处理车型确认与适配复核。
接口状态应该怎么落库？
应至少区分传输状态、业务状态和匹配状态三层。HTTP 请求成功只说明服务端收到并返回了响应，不代表业务查询成功；官方示例还会检查响应中的 status，只有业务状态符合文档定义时才继续读取 result。
推荐把一次查询记录为以下状态：
- 传输状态：超时、网络失败、非预期 HTTP 状态。
- 鉴权与额度状态：APPKEY、权限、请求次数或接口维护等系统状态。
- 业务输入状态：车型 ID、VIN、分类 ID、名称或零件号是否符合当前接口要求。
- 匹配状态：无结果、单一候选、多个候选、待人工核验。
错误码必须按每个接口自己的文档解释，不能把车型零件搜索的错误码直接套到全车件或车型大全接口。例如，车型零件搜索文档对 VIN、车型 ID、零件名长度和零件号设置了具体错误说明，这些说明只应在对应接口范围内使用。
接入时还要注意哪些边界？
APPKEY 应保存在服务端环境变量或密钥管理系统中，不应放入浏览器、小程序前端或公开仓库。本文请求只展示文档结构，没有实际发起查询，也不代表接口已经完成业务测试。
上线前建议使用少量、可公开或已脱敏的测试数据验证：车型树是否能稳定保存、分类是否递归到末级、业务 status 是否正确处理、无结果是否进入人工复核，以及日志是否对 VIN、APPKEY 等信息脱敏。
需要开始接入时，可先查看极速车服全部 API，再按系统职责分别进入车型大全、销售车型全车件查询和车型零件搜索文档。先拆职责再写代码，后续扩展 VIN、OE 或保养业务会更容易维护。
