在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
处理没有门牌号的地址
并非每个地址都有门牌号。乡村道路、一些新开发的区域以及知名地标，在提及时往往不带门牌号，而一个每次都预期有门牌号的地理编码请求，会误解这类地址的有效结果应该是什么样子。
没有门牌号时响应是什么样子
GET /v1/forward?q=Golden Gate Bridge, San Francisco&limit=1{
"status": "ok",
"query": "Golden Gate Bridge, San Francisco",
"results": [
{
"formatted": "Golden Gate Bridge, San Francisco, CA",
"lat": 37.8199,
"lon": -122.4783,
"type": "address",
"precision": "street",
"confidence": 0.9,
"place_id": "gb567",
"components": {"city": "San Francisco", "region": "CA", "country": "US"}
}
]
}请注意，这里的 components 中没有 house_number 字段，而且 precision 的值是“street”而不是“house”。对于确实没有门牌号的地址来说，这两点都是预期之内的，并不表示查询失败或只完成了一部分。
正确理解 precision
请将 precision 视为对匹配具体程度的描述，而不是错误指示。“house”精度表示匹配解析到了一栋具体的建筑物。“street”精度表示匹配解析到了一条街道或街道上的某一点，但没有确定到具体的建筑物，这对于地标或确实没有门牌号的地址来说完全正确。
第二个示例：知名的公共场所
GET /v1/forward?q=Central Park, New York&limit=1像这样有名称的公共场所，解析结果中的 type 通常是比“address”更宽泛的类型，precision 反映的是一个区域而不是单个点，components 对象可能只包含城市和地区。这与桥梁示例的规律相同：一个真实、有用的结果，如实地描述为覆盖一个区域而不是一栋具体的建筑物，因为查询实际所指的正是这样一个区域。
相应调整验证逻辑
如果您的表单验证目前要求必须存在 house_number 字段才认为地址完整，这一检查会错误地拒绝合法的乡村地址和地标。请根据 confidence 和 precision 是否符合您的实际需要来制定接受标准，而不是要求每个具体组成部分都必须有值。
需要避免的常见错误
不要将空的 components 对象或缺少若干字段的 components 对象等同于失败的请求。失败的请求会返回错误状态和错误代码，详见错误文档。组成部分稀少的成功结果是另一种完全正常的结果，如果在错误处理中将两者混为一谈，有效的地址就会被记录并当作失败处理。
让客户确认而不是拒绝
对于没有门牌号的地址，将格式化后的结果展示给客户确认，比直接拒绝提交效果更好。这样既能让真实地址保持可用，又能在其他环节捕获真正错误的输入。
反向查询也遵循同样的规律
同样，对位于开阔乡野或水域中的坐标进行逆地理编码，返回的精度可能更粗，有值的组成部分也更少，而位于某栋具体建筑物轮廓内的坐标则不会如此。逆地理编码文档从这一方向介绍了同样的 precision 值。
费用保持不变
没有门牌号的地址与其他任何正向地理编码查询一样，只消耗一个请求。缺少组成部分不会改变该请求在您的每日配额或额度余额中的计费方式。
正确处理这种情况，关键在于按照设计意图理解 precision 和 confidence，而不是假定每个有效地址都必须填满每个组成部分。正向地理编码文档详细解释了每个字段。