EPC 全车件接口要分两步调用：先用已确认的 carid 或 VIN 获取目录层级，再用末级 classid 查询零件。classid 是分类 ID，查询结果也不等于最终适配保证。
第一个请求怎样获取 EPC 分组？
极速车服（jisuepc）的销售车型全车件查询 API当前提供 https://api.jisuepc.com/epc2/class 获取分组，支持用 carid 或 VIN 作为车型输入，返回 classid、name 和 isend。isend 用于判断当前节点是否为最后一级，文档要求查询配件时使用最后一级 classid。
已有确认的车型 ID 时，建议优先使用 carid，示例结构如下：
curl --request GET "https://api.jisuepc.com/epc2/class?carid=YOUR_CARID&appkey=YOUR_APPKEY"
这是文档结构模板，不会发起真实请求。若改用 VIN，应先确认 VIN 识别结果能够锁定车型，并注意 EPC 页面说明：查到结果时同一 VIN 首次与当天重复查询的计次规则不同，具体权益以当天页面为准。
为什么不能一次请求“返回全部配件”？
分组接口的结果是目录树，可能先出现“车身部分”等一级节点，再继续展开到具体部位。程序应保存每个节点的 classid、名称和父子路径，直到 isend 表示叶子节点。
第二个请求使用 https://api.jisuepc.com/epc2/parts。官方参数说明要求 classid，车型输入可使用 carid 或 VIN，并可选 keyword、isfilter。返回结果包括 partsid、name、number、number2、stdname、remark 和 num 等字段：
curl --request GET "https://api.jisuepc.com/epc2/parts?classid=YOUR_CLASSID&carid=YOUR_CARID&appkey=YOUR_APPKEY"
页面参数表同时将 carid 标为必填，说明文字又写明 carid 和 VIN 至少选一个。为避免把页面粒度差异误写成确定规则，已有 carid 时优先传 carid；只使用 VIN 的方案应先在联调环境确认当前参数要求。
程序应怎样保留状态？
建议把车型、目录和零件拆成三个状态：
| 阶段 | 输入 | 应保留的结果 | 失败时回到哪里 |
|---|---|---|---|
| 车型确认 | VIN 或已确认 carid | 车型 ID、来源和人工确认状态 | VIN/车型资料层 |
| 分组展开 | 车型标识 | classid、名称、父子路径、isend | 目录分组层 |
| 零件查询 | 末级 classid + 车型标识 | partsid、OE 号、名称、备注和数量 | 参数或数据范围层 |
内部可以使用 category_pending、leaf_selected、parts_found 和 manual_review 等状态名，但这些不是官方接口字段。不要把分类 ID 当成配件唯一身份，也不要只保存显示名称而丢掉车型和分组路径。
查到 OE 号后还要核验什么？
目录定位完成后，仍需核对车型年款、动力、变速箱、车身版本、左右侧、安装位置、接口、尺寸以及旧件标识。若结果带有替换关系，应区分原始号、替换号和品牌件号；库存、价格和质保则要由企业或供应商另行确认。
因此，EPC 接口解决的是“在已确认车型的目录中找到哪些零件”，不自动替代技师的实物核验，也不构成采购承诺。
错误和安全边界怎么处理？
当前 EPC2 文档列出的业务错误包括 201 分组 ID 错误、202 车型 ID 错误、203 VIN 不正确、204 VIN 无法锁定车型和 220 没有信息；系统错误还包括 APPKEY、权限、次数限制、IP 和维护状态。程序应把车型、当前分组路径、请求编号和错误类别一起保存，不要把所有失败都提示为“没有配件”。
APPKEY 只放在服务端环境变量或密钥管理服务中。本文代码使用占位符，没有发起真实请求；接口地址、参数、错误码和计次规则变化时，应回到当前 EPC2 API 文档复核。
总结
EPC 全车件接口的稳定链路是“确认车型、获取分组、判断 isend、使用末级 classid 查配件、再复核 OE 和实物”。把两个端点和三个业务状态分开，才能解释空结果、保留查询上下文，并避免把分类或目录结果误当成最终适配。
