很多团队第一次算这笔账，都是从"我们自己也能做"开始的。
自建的成本从来不只是开发工时。第一块是数据获取，车型公告、电池参数、续航数据分散在工信部公告、厂家官网、第三方数据库里，口径还不统一；第二块是持续更新，新车型每月都在进来，停产车型的配置还要保留历史版本，不然老车查不到；第三块是隐性成本，为了匹配"用户输入的车牌和库里的车型"，得做清洗、模糊匹配、人工兜底复核，一套下来就是个小团队。
按次采购的账就简单得多 。电动汽车车牌查询接口按调用量计费，单次成本在几毛钱这个量级，新用户还有一万次免费测试额度。一家月均查询两万次的二手车平台，一个月费用不到一万块，没有前期投入、没有运维人力、没有版本升级的排期。业务量涨了费用同比例涨，业务量掉了费用跟着掉，不存在当年建好、今年没人用的沉没成本。
更实际的一点是决策速度。自建方案从立项到上线，行业里普遍要三到六个月；接一个成熟接口，通常一周内能跑通，半个月能上线。对于门店扩张、区域试点这类需要快速验证的场景，时间本身就是成本。
当然，按次采购也不是无脑选。日调用量稳定在几十万次以上、且字段要求高度定制化的团队，自建或混合方案可能更划算。但对绝大多数做二手车 SaaS、车队管理、充电运营的公司来说，业务量还没到那个量级，先背上一个车型库的固定成本，是把弹性换成了负担。
有个客户的做法挺聪明：核心场景用接口，边缘场景用人工。收车必须查配置，这是核心，走接口；年度的车型库盘点这种低频动作，抽样加人工核对。既控制了成本，也没在关键节点上留漏洞。
还有一笔容易被忽略的成本：机会成本。负责自建的同学原本可以去做成交链路优化，结果半年时间花在给不同厂家对齐电池参数上。这笔账不会出现在财务报表里，但它真实发生了 。算成本这件事，别只算服务器和人力，算上"上线晚了三个月少赚的钱"和"维护这套车型库要占掉几个人的注意力"，答案通常就清楚了。
转化路径设计：
import requests # 按次计费，先跑通再谈量：单条查询验证成本模型 url = "https://api.jiguangdata.com/vehicle/v1/ev/plate/query" headers = {"Authorization": "Bearer YOUR_API_KEY"} payload = {"plate_no": "京AD12345", "plate_color": "green"} r = requests.post(url, json=payload, headers=headers, timeout=5).json() print(r["data"]["charge_units"], r["data"]["model"]) # 计费单位与车型
