不能直接拼接url调用高德/百度/腾讯地图api，因为各家逆解析接口的参数名、认证方式、坐标顺序（如高德先经后纬、百度腾讯先纬后经）、坐标系要求（wgs-84/gcj-02/bd-09）及返回结构完全不同，硬拼易导致400错误或位置偏移数百米；需通过中间协议统一输入输出，并强制坐标系转换与并发降级策略。
为什么不能直接拼接 URL 调用高德/百度/腾讯地图 API
因为各家逆解析（即 geocode 或 regeocode）接口的参数名、认证方式、返回结构完全不同，硬拼 URL 容易 400 或返回空结果。比如高德用 key 和 location，百度要 ak + coordtype + location（且顺序敏感），腾讯则要求 key 放 query，location 格式为 lat,lng（注意是先纬后经）。更麻烦的是百度默认返回 GCJ-02 坐标系，而你传入的可能是 WGS-84 —— 不做坐标系转换，位置会偏移几百米。
如何统一输入输出，避免每个服务都写一遍逻辑
核心是定义一个中间协议：输入固定为 { lat: number, lng: number, coordType?: 'wgs84' | 'gcj02' }，输出统一为 { address: string, city: string, district: string, adcode: string, formattedAddress: string }。所有适配器只负责「把中间协议转成服务商要求的请求」和「把原始响应映射到中间协议」。
- 高德：用
https://restapi.amap.com/v3/geocode/regeo，location填${lng},${lat}（注意是先经后纬），output=json必须显式加 - 百度：用
https://api.map.baidu.com/reverse_geocoding/v3/，location是${lat},${lng}（先纬后经），必须指定coordtype=wgs84ll或gcj02ll，否则默认用百度自家坐标系 - 腾讯：用
https://apis.map.qq.com/ws/geocoder/v1/，location是${lat},${lng}，但需在请求头加Referer（哪怕填 localhost），否则 403
怎么处理并发请求与降级策略
别等一个失败再试下一个——网络抖动或配额超限很常见。推荐并发发三路请求，用 Promise.race() 拿最快的成功响应，同时用 Promise.allSettled() 记录各路状态供后续分析。但要注意：百度接口有严格 QPS 限制，如果全量并发可能被限流；建议加一层简单令牌桶，或对百度单独设 delay(200) 避免触发风控。
降级逻辑写死在适配器里：比如高德返回 status !== 1、百度返回 status !== 0、腾讯返回 status !== 0，就跳过该结果；最终无一成功时，返回 { address: '定位失败', formattedAddress: '无法解析该坐标' }，不抛异常。
坐标系转换不是可选项，而是必做步骤
WGS-84（GPS 原始坐标）→ GCJ-02（高德/腾讯国内标准）→ BD-09（百度专用）之间必须转换，否则地址偏差显著。不要手写转换公式——精度差且易出错。用现成库：coordtransform（npm 包）或 gcoord，它们已验证过边界情况（如黑龙江漠河、新疆帕米尔高原）。
实际调用前判断：
– 若输入 coordType === 'wgs84'，且目标平台是百度，则先用 gcoord.transform([lng, lat], gcoord.WGS84, gcoord.BD09) 转换；
– 若目标是高德/腾讯，且输入是 wgs84，则转 GCJ-02；
– 输入已是 gcj02，百度仍需再转一次 BD-09。
这个步骤漏掉，模块上线后你会发现上海陆家嘴解析成杭州西湖区。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
