做GIS（地理信息系统）这行十年了，我见过太多人为了搞个“附近的人”或者“区域围栏”功能，把服务器CPU干到99%，最后还说是算法不行。其实，90%的问题出在架构选型上。今天咱们不聊虚的，就聊聊怎么用Lua做geo匹配，怎么让它既快又准，还不掉坑里。

先说个真事儿。去年有个客户，做外卖配送的，初期用MySQL的ST_Distance函数查附近商家。数据量小的时侯还行，一旦并发上来，查询延迟直接飙到2秒以上。用户骂娘，老板骂我。我当时就说了，这种场景根本不该用关系型数据库做实时计算。后来我们切到了Redis+Lua的方案，响应时间压到了10毫秒以内。这差距，简直是天壤之别。

为什么选Lua？因为快。Lua是嵌入式的脚本语言，执行效率极高，而且支持原子操作。在Redis里跑Lua脚本，意味着你的逻辑和数据处理都在内存里完成，不用来回IO。这对于geo匹配这种高频、低延迟要求的场景，简直是绝配。

但这里有个大坑，很多人不知道。GeoHash虽然简单，但它有个致命缺陷：边界效应。想象一下，一个点就在两个网格的交界线上，它可能被判定为“附近”，也可能被判定为“很远”，这取决于它落在哪个格子里。这种不稳定性在业务上是不可接受的。所以，我强烈建议不要用纯GeoHash做核心匹配逻辑。

那怎么做才靠谱？我的建议是：分层过滤+精确计算。

第一步，用Redis的GEO命令或者GeoHash做粗筛。比如，你要找半径5公里内的用户，先圈出一个正方形区域，把候选集捞出来。这一步很快，因为它是基于索引的。

第二步，在Lua脚本里进行精算。拿到候选点后，用Haversine公式或者更精确的球面距离公式，计算每个点与目标点的真实距离。这一步虽然比粗筛慢，但因为数据量已经大幅缩小，所以完全在可控范围内。

这里有个细节，很多同行会忽略。就是坐标系的转换。如果你的业务涉及全球范围，一定要用WGS84坐标系。国内的话，GCJ-02或者BD-09也得注意转换。我之前踩过一个坑，就是没注意坐标系偏差，导致匹配结果偏移了大概200米。这在打车软件里是事故，在电商配送里可能就是投诉。

再说说性能优化。Lua脚本一旦加载，就会缓存在Redis节点里。所以，脚本写得越短越好，逻辑越简单越好。别在Lua里搞复杂的循环或者递归。如果逻辑特别复杂，建议拆分成多个小脚本，或者在应用层做预处理。

另外，缓存策略也很重要。geo匹配的结果往往具有局部性。也就是说，附近的用户，他们的匹配结果大概率也是相似的。你可以做一个简单的LRU缓存，Key可以是“目标点坐标+半径”，Value是匹配结果。这样能进一步减轻Redis的压力。

最后，总结一下。Lua geo匹配的核心在于：粗筛用Redis索引，精算用Lua脚本，缓存做兜底。别指望一个函数解决所有问题，分层处理才是王道。

我见过太多团队为了追求“新技术”而引入复杂的分布式图数据库，结果维护成本极高，性能提升却微乎其微。对于大多数中小型项目，Redis+Lua的组合足够强大，也足够稳定。

当然，凡事无绝对。如果你的数据量达到亿级，或者对实时性要求极高，可能需要考虑Elasticsearch的geo_point类型，或者专门的GIS数据库如PostGIS。但对于90%的场景，Lua geo匹配依然是性价比最高的选择。

别怕麻烦，前期架构设计多花一小时，后期运维能少掉两根头发。这就是经验之谈。希望这篇文章能帮你少走弯路，早点下班。