在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
将表单提交限制在配送半径内
只覆盖特定区域的配送服务，需要一种在下单之前就拒绝区域外地址的方法，而不是等到派单时由司机发现。
对提交的地址进行地理编码
当客户提交收货地址时，在接受订单之前先对其进行地理编码。
GET /v1/forward?q=10 Downing Street, London&limit=1{
"status": "ok",
"results": [
{"formatted": "10 Downing Street, London, UK", "lat": 51.5033, "lon": -0.1276, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "op678", "components": {}}
]
}与配送中心进行比较
拿到客户的坐标和您固定的配送中心坐标后，在您自己的代码中使用标准的半正矢（haversine）公式计算两者之间的直线距离，并与您的配送半径进行比较。
distance_km = haversine(hub_lat, hub_lon, 51.5033, -0.1276)
if distance_km > max_radius_km:
reject_order()拒绝之前先检查置信度
地理编码结果的置信度分数低，意味着地址本身存在歧义，并不一定意味着它位于您的半径之外。请将低置信度匹配与明确超出半径的拒绝分开处理，例如请客户确认或完善地址，而不是直接拒绝订单。
第二个例子：在多个配送中心中选择最近的一个
运营多个配送中心的企业，应计算到每个配送中心的距离，而不只是一个，只要任一配送中心的半径覆盖该地址，就接受订单。把订单分配给距离最近的配送中心，也能通过同一次计算把履约环节正确地安排好，因为一旦按距离排序，您就已经知道胜出的是哪个配送中心。
nearest_hub = min(hubs, key=lambda h: haversine(h.lat, h.lon, cust_lat, cust_lon))
if nearest_hub.distance_km > nearest_hub.max_radius_km:
reject_order()需要避免的常见错误
不要在 distance_km 仅仅以微小差距（例如几十米）超过 max_radius_km 时，就立即拒绝订单，而不给客户任何解释或补救途径。地址恰好落在边界线上，是在地图上画半径的正常结果；对于住在一条自己看不见的线外两条街的客户来说，没有任何说明的一口回绝显得很武断。显示计算出的距离和覆盖半径，而不是一个光秃秃的拒绝，至少能解释原因。
使用直线半径与实际覆盖范围
直线半径是一种简单的近似，偶尔会把按道路计算实际上很远的点包括进来，或者把按道路很近但直线距离较远的点排除在外，例如隔着一条附近没有桥的河。对于大多数配送区域检查来说，这种近似已经足够，要进一步细化，就需要地理编码查询所提供范围之外的路径规划数据。
成本是多少
每次地址检查是一次地理编码请求；如果您通过单独调用将地址与配送中心列表逐一比较，而不是在本地复用同一组坐标，则每个候选配送中心各算一次请求，但实际上只有地址本身需要地理编码，而不是每个配送中心。对于典型的本地企业，检查每一笔提交订单的配送表单完全在每个密钥所含的每天 2,500 次免费请求之内，只有当订单量大幅增长时才会转为使用预付额度。
在提交时而不是派单时拒绝区域外的订单，可以为双方省去日后一场白费口舌的沟通。完整的参数说明见正向地理编码文档，当前的价格档位见价格页面。