做这行九年，我见过太多人为了搞个地图搜索功能，把头发都愁秃了。特别是搞geo2d范围查询这块，网上教程一堆，真上手一跑，数据对不上，距离算不准，最后还得自己擦屁股。我就纳闷了，明明是个基础功能，怎么就搞得这么玄乎？今天我不讲那些虚头巴脑的理论，就聊聊我踩过的坑，怎么把这块硬骨头啃下来。

先说个真事儿。去年有个做同城配送的小兄弟找我，说他的系统里，用户搜“附近5公里”，结果出来一堆在8公里外的店，还有几个明明在隔壁省的数据也跳出来了。我一看后台日志，好家伙，经纬度精度都没保留，直接截断了，这能准吗？这就像你拿着把只有厘米刻度的尺子去量操场，还能跑出个吉尼斯纪录？

第一步，得把坐标系搞对。这是最基础的，也是最容易翻车的。国内大部分地图服务，比如高德、百度，用的都是GCJ-02或者BD-09坐标系，而你的数据库里存的要是WGS-84，那直接差出几百米去。别偷懒，入库前必须做转换。我有个习惯，就是在数据进来的时候，先统一转成WGS-84存着，查询的时候再按需转换，或者干脆在数据库层面做映射。这一步省不得，否则后面全是废数据。

第二步，建索引。很多新手不知道，普通的B-Tree索引对地理空间查询根本没用。你得用GeoHash或者R-Tree。GeoHash简单粗暴，把经纬度变成一个字符串，前缀相同的就在附近。比如我做的这个geo2d范围查询，就是用GeoHash做预筛选，先把大致范围圈出来，然后再用精确算法算距离。这样速度能快好几倍。别一上来就全表扫描，服务器会哭给你听的。

第三步，精确计算。GeoHash虽然快，但它有个毛病，就是边界效应。两个点可能在GeoHash网格的两侧，看起来很远，其实直线距离很近。所以，预筛选之后，必须用Haversine公式或者球面余弦定理算一次精确距离。这一步虽然耗CPU，但为了保证准确性，没法省。我一般是在应用层做这个二次过滤，数据库只负责返回候选集。

第四步，测试边界情况。这点太重要了。我见过太多项目，平时跑得好好的，一到城市边缘或者跨区的时候，数据就乱了。你得专门找一些边界点做测试，比如两个城市交界处，或者经纬度正好在网格边缘的点。我有一次就栽在这里，因为没考虑到经度跨越180度时的处理，导致太平洋那边的数据全乱了，尴尬得我想找个地缝钻进去。

还有个小细节，就是精度问题。经纬度保留几位小数？6位大概是一米，7位是十厘米。对于大多数业务场景，6位够了，再高精度反而浪费存储和计算资源。别盲目追求高精度，够用就行。

最后，别忘了监控。上线后，盯着查询耗时和返回结果的数量。如果突然飙升，可能是索引失效了，或者数据源出了问题。我有个项目，因为某个字段索引失效，导致一次geo2d范围查询变成了全表扫描，服务器直接宕机，那次教训让我至今心有余悸。

总之，搞geo2d范围查询，没那么复杂，但细节决定成败。别信那些“一键生成”的神器，自己动手，丰衣足食。把坐标系搞对，索引建好，计算算准，测试做足，这事儿就成了。希望我的这些血泪经验，能帮你少掉几根头发。毕竟，头发没了，还能长；项目崩了，可就真没处哭去了。

本文关键词：geo2d范围查询