在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
使用逆地理编码构建门店查找工具
门店查找工具需要两样东西配合：一种知道顾客在哪里的方法，以及一份用于比较的门店坐标列表。逆地理编码能干净利落地解决第一部分。
把坐标转换为可读的位置
获得顾客的坐标后（来自顾客输入的位置或 IP 查询），对其进行逆地理编码，向顾客显示一个可读的地名，在展示结果之前确认搜索位置。
GET /v1/reverse?lat=51.5074&lon=-0.1278{
"status": "ok",
"formatted": "Trafalgar Square, London, UK",
"lat": 51.5074,
"lon": -0.1278,
"type": "address",
"precision": "street",
"confidence": 0.9,
"place_id": "lm345",
"components": {"city": "London", "country": "GB"}
}查找最近的门店
API 返回的是坐标，而不是任意两点之间的距离，因此获得顾客的纬度和经度后，请对两组坐标使用标准的大圆距离算法，计算到您列表中每家门店的距离。按计算出的距离对门店列表排序，并显示最近的几家。
让顾客改为输入地址
并非每位访客都会分享自己的位置。对于输入地址的搜索，先用 /v1/forward 对输入的文本进行地理编码以获取坐标，再用该结果运行同样的最近门店距离计算。如果您希望在顾客输入时就出现建议，而不是等待完整地址，可以用 /v1/autocomplete 支持一个输入联想字段，把 place_id 或解析后的文本传入同一个正向地理编码步骤。
第二个示例：使用设备 GPS 的移动应用
原生应用在查找附近门店时可以跳过逆地理编码步骤，因为它已经拥有设备的原始坐标，可以直接与您的门店列表比较。不过逆地理编码在这里仍有用武之地，可用于向顾客显示确认文本，例如“正在显示伦敦特拉法加广场附近的门店”，而不是一对光秃秃的数字，这能让顾客在浏览结果之前确信应用正确理解了自己的位置。
需要避免的常见错误
在进行距离计算之前，不要假设每个输入的地址都能地理编码到门牌级精度。像只有城市名称这样的宽泛查询仍会返回结果，但精度较粗；如果把这个粗略的点当作精确定位到顾客所在的建筑，您的“最近门店”排序就会比 confidence 和 precision 字段所提示的更不可靠。
处理两家邻近门店距离相同的情况
当两家门店计算出的距离几乎相同时，仅凭距离无法告诉顾客哪一家真正更适合自己。同时显示两家，并附上营业时间或库存情况等详细信息，能让顾客获得决定性的依据，而不是一个随意的排序。
确认匹配结果
在门店结果旁边显示逆地理编码结果中的格式化地址，让顾客能立即看出检测或解析到的位置是否与自己真正想搜索的位置一致，如不一致可以更正。
成本是多少
每次搜索就是一次逆向或正向地理编码请求，无论之后与多少家门店比较，因为一旦双方都有了坐标，距离计算本身就在您自己的代码中进行。每天有中等流量的门店查找工具，可以轻松地落在每个密钥附带的每天 2,500 次免费请求之内。
这样构建的门店查找工具，每次顾客搜索只需要一次地理编码请求，之后的一切都在本地针对您自己的门店列表处理。完整的响应字段请参阅逆地理编码文档。