做搜索定位，最怕的就是搜“北京”出来一堆“北京烤鸭”的店，或者明明在朝阳区却搜不到附近的店。这篇就是教你怎么让es的geo功能真正跑起来，不踩那些让人头秃的坑，直接上干货。

先说个真事儿，上周有个兄弟找我哭诉，说部署了半天es，geo_point死活查不准，数据丢了一半。我一看他的mapping，好家伙，经纬度写反了，而且没开doc_values。这种低级错误，新手最容易犯。记住啊，es的geo功能虽然强大，但前提是数据得干净，格式得对。

咱们聊聊最常见的geo_point类型。很多老手都容易忽略一点，就是坐标系的转换。国内一般用GCJ-02或者BD-09，而es默认支持的是WGS-84。你要是直接往es里灌高德或者百度的坐标，那位置偏差能有几百米甚至上公里。这可不是闹着玩的，做LBS应用的，差几米用户就骂娘了。所以，在数据入库前，务必做好坐标转换，或者在es里用script动态转换，虽然牺牲点性能，但数据准啊。

再说说性能问题。很多兄弟一上来就搞geo_distance查询，数据量一大，集群直接卡死。为啥？因为geo查询默认是全表扫描或者全分片扫描。这时候，你得学会用geo_shape或者geo_hash。特别是geo_hash，它能利用字符串的前缀匹配，大大减少查询范围。比如查“附近5公里”，你可以先算出中心的geo_hash前缀，再查相邻的hash值。这样查询速度能提升好几倍。当然，这也得看你业务场景，如果精度要求不高，geo_hash是神器。

还有一个大坑，就是聚合查询。很多业务方想要“按区域统计销量”，直接用geo_distance_aggregation。结果发现，边界数据重复计算或者漏算。这是因为geo_polygon的闭合问题。es在处理不规则多边形时，如果顶点顺序不对，或者多边形自相交，结果就会乱套。解决办法是，入库前用GeoJSON校验工具把多边形处理干净，确保是合法的简单多边形。别偷懒，这一步省不得。

关于索引优化，我也得提一嘴。geo_point字段默认是不分词的，但如果你要频繁做范围查询，建议把lat和lon拆分成两个double字段，配合range查询。虽然牺牲了一点灵活性，但查询效率确实高。不过，如果你需要复杂的地理围栏判断，那还是老老实实用geo_point吧。没有银弹，只有最适合场景的方案。

最后说说监控。es的geo查询很吃内存，特别是涉及大量聚合的时候。一定要盯着heap的使用率。如果heap爆了，gc频繁，整个集群都会抖。我在生产环境里，通常会给geo查询设置timeout，防止慢查询拖垮集群。另外，定期清理过期的地理位置数据，别让它堆积如山。

总之，es的geo功能不是拿来即用的，得调教。从数据清洗、坐标系转换，到查询策略、索引优化，每一步都得抠细节。别指望一键解决所有问题，那都是骗人的。只有真正深入理解原理，才能在实际项目中游刃有余。

希望这些经验能帮到你。要是还有啥具体问题，欢迎留言讨论。咱们一起把es玩明白，别让它成了你的绊脚石。记住，细节决定成败，尤其是在处理地理位置数据的时候，稍微马虎一点，后果都很严重。加油吧，打工人！