记得刚接手那个基于地理位置的搜索项目时，我觉得 geo_point 简直就是个黑盒，只要扔进去经纬度就能跑。直到那天凌晨两点，监控报警群炸了，说是搜索功能大面积失效，查日志一看，全是解析错误。那一刻我才意识到，对 geo_point 取值范围的理解偏差，能直接让生产环境瘫痪。今天不整那些虚头巴脑的官方文档翻译，就聊聊我在这上面摔过的跟头，以及怎么才算真正搞懂了 geo_point 取值范围。
先说个最基础的误区。很多人以为经纬度随便填，只要符合常识就行。比如纬度 -90 到 90，经度 -180 到 180。这没错，但在实际业务中，如果你把纬度设成 91，或者经度设成 181，ES 会直接抛异常。别小看这种低级错误，我在测试环境因为复制粘贴代码，把纬度写成了 95，结果整个索引重建失败，排查了半小时才发现是个数字越界。这就是 geo_point 取值范围的第一层含义：物理边界。纬度必须在 [-90, 90] 之间，经度必须在 [-180, 180] 之间。超出这个范围，连存储都存不进去，更别提查询了。
但真正让人头疼的，是第二层含义：精度与性能平衡。geo_point 底层用的是 Geohash 或者 QuadTree 算法。当你输入的坐标精度太高，比如保留小数点后 10 位，ES 内部生成的哈希值会变得非常长，不仅占用更多磁盘空间，还会显著降低查询速度。我有个客户，之前为了追求“极致精准”，在坐标里存了 8 位小数，结果查询响应时间从 50ms 飙到了 200ms。后来我们调整策略，将坐标精度控制在 5-6 位小数，也就是大概 1 米左右的精度，对于大多数 LBS 业务来说完全够用，查询性能立马回归正常。这里要注意，geo_point 取值范围虽然允许高精度，但没必要追求无限精度，适度裁剪才是明智之举。
再说说边界情况。很多开发者容易忽略极点和国际日期变更线附近的坐标处理。比如在北极点附近，经度的意义会发生变化，如果直接做范围查询，可能会出现逻辑错误。我遇到过一次，用户查询“北极圈附近的所有加油站”，结果返回了南半球的数据。原因是查询时的边界判断没有考虑到球面几何的特性，简单的矩形框查询在极地附近会失效。这时候，我们需要借助 ES 提供的 geo_distance 查询，并明确指定单位，同时注意坐标的归一化处理。这虽然不是直接的取值范围问题，但却是使用 geo_point 时最容易踩的坑。
还有一点，关于 null 值和空值的处理。如果某个地点的经纬度缺失，ES 默认会将其视为无效数据，不会建立倒排索引。这意味着，如果你用 geo_distance 查询，这些缺失数据的地点永远不会出现在结果中。我在做数据清洗时，发现大约有 5% 的旧数据存在经纬度为空的情况，导致搜索结果不完整。解决办法是在写入前进行校验，或者在查询时明确排除这些无效数据。
最后，给兄弟们几个实操建议。第一，入库前务必校验经纬度是否在 [-90, 90] 和 [-180, 180] 范围内，可以用代码写个简单的断言，别等上线了再查日志。第二，控制小数点位数，一般 5-6 位足够，除非你是做高精度测绘，否则没必要存更多。第三，查询时注意单位统一，米、公里、英里搞混了，结果差之千里。第四，定期监控 geo_point 字段的写入失败率，如果突然升高，可能是数据源出了问题。
别指望一次就能把 geo_point 玩转，这玩意儿得在实战里磨。如果你也在为坐标查询慢或者报错头疼，不妨回头看看是不是取值范围或者精度设置上出了问题。有问题欢迎在评论区留言，咱们一起聊聊那些踩过的坑。
