用边界情况而不只是理想路径来测试位置数据
一个位于地图完善的市中心的地址，几乎无法告诉您系统如何处理乡村路线、有争议的边界或靠近两极的查询。请有意识地测试这些困难情况。
地址解析的歧义：公寓、单元和邮政信箱
拿一行像 “12B Flat 3” 这样的地址，问问每个部分是什么意思，您会发现答案取决于惯例，而不是字符串本身。“12B” 是带字母后缀的楼号，还是楼层和单元的组合？“Flat 3” 是指 12B 号楼内某个具体单元的单独限定词，还是与它重复？熟悉当地惯例的人能立刻判断。而解析来自世界各地任意自由文本的软件就要费力得多，因为同样的字符根据地址的来源会有不同的含义。
单元和公寓标识在不同国家之间，甚至在同一国家内部，都差异很大。像 “Apt”、“Unit”、“Ste”、“Fl” 这样的缩写，或者逗号后的一个单独数字，都可能表示建筑内的某个子单元，而不同国家乃至同一国家的不同地区偏好不同的惯例。针对某个地区习惯调校的解析器，会经常误读另一个地区的地址，要么完全丢掉单元信息，要么把它附加到地址的错误部分。
邮政信箱又带来另一个麻烦，因为它代表的是一个邮寄目的地，与任何实体建筑都没有直接对应关系。从属于某个具体邮局的意义上说，邮政信箱确实有真实而有意义的位置，但把它地理编码到该邮局的坐标，与对街道地址进行地理编码是两回事；如果您的用例实际上需要一个实体投递点，把两者等同处理，就会得到一个看似合理、实际上毫无用处的结果。
精度和置信度字段存在的部分原因，正是为了呈现而不是掩盖这类歧义。包含未解析或有歧义的单元标识的地址，仍可能在建筑级别成功完成地理编码，此时 precision 反映的是匹配在建筑级别成功，而不是确认具体子单元已被正确解析。如果只读取坐标而忽略精度，就可能误以为已经定位到了某套具体的公寓，而实际上只定位到了建筑。
如果您的应用依赖单元级精度，例如向大型小区内的某套具体公寓送货，就值得验证单元或公寓字段确实被解析并单独保留，而不是被悄悄并入一个只解析到建筑的匹配结果中。用包含单元标识、邮政信箱和多段式建筑标识、来自多个不同国家的真实示例来测试您的地址输入，而不仅仅是您本土市场的格式，就能在用户发现之前暴露这类缺陷。我们的正向地理编码端点返回 type 和 precision 字段，正是为了让您区分完整匹配和建筑级近似结果。