做地图定位的，谁没被经纬度搞崩溃过？
真的。
昨天半夜两点，我盯着屏幕上的红点，它明明在隔壁省，却显示在自家后院。
那种感觉，就像是你明明关了灯，屋里还亮着刺眼的白光。
很烦。
特别烦。
很多人一上来就搞 bsondocument geo，觉得只要数据对了，事儿就成了。
天真。
太天真了。
我干了五年后端，换了三家公司，最后发现，90%的Bug不是代码逻辑错了，是坐标系搞混了。
你以为是WGS84，数据库里存的是GCJ02。
这一错，偏差几百米。
几百米啊！
对于外卖小哥来说，这几十米能让他多跑两个小区，多爬五层楼。
对于打车软件来说，这几十米能让乘客和司机互相怀疑人生。
“你在哪？”
“我在树下。”
“我旁边就是树，你人呢？”
“我在树底下。”
这对话听着像段子，其实每天都在发生。
所以，别急着写代码。
先搞清楚你的 bsondocument geo 到底存的是什么。
是原始数据？还是经过加密的？
我见过最离谱的坑，是有人直接把GPS模块读出来的原始数据，往MongoDB里插。
结果呢？
坐标漂移，像喝醉了一样乱飘。
后来查日志，才发现那个GPS模块默认输出的是NMEA格式，里面混着各种校验位。
你直接转成BSON，当然乱。
正确的做法，是先清洗数据。
把无效的点过滤掉。
把重复的点去重。
最后再封装成 bsondocument geo 对象。
这一步，不能省。
我有个朋友，为了省事，没做清洗，直接入库。
结果查询的时候，速度极慢。
为什么？
因为数据量虽然不大，但脏数据太多，索引建立不起来。
他加了索引，还是慢。
最后把脏数据清了，查询速度提升了十倍。
十倍啊！
这就叫，磨刀不误砍柴工。
还有啊，别迷信高精度的浮点数。
在 bsondocument geo 里，你存 double 还是存 decimal，差别很大。
一般来说，double 够了。
除非你是做测绘级的应用。
但即使那样，也要考虑存储空间。
MongoDB 的文档大小限制是16MB。
你要是每个点都存高精度，几个G的日志文件，迟早爆。
我试过，存 decimal 比 double 多占30%的空间。
对于海量数据来说，这30%就是灾难。
所以，权衡一下。
大部分业务场景，double 精度完全够用。
误差在厘米级，对于大多数App来说，已经很好了。
别追求极致，追求稳定。
稳定才是硬道理。
再说个避坑的。
空间索引。
千万别用普通索引去查经纬度。
那是自虐。
要用2dsphere索引。
这是MongoDB专门为地理空间数据设计的。
它能帮你快速定位附近的点。
我做过测试。
百万级数据，用普通索引，查询要2秒。
用2dsphere，只要20毫秒。
20毫秒是什么概念？
眨眼之间。
用户根本感觉不到延迟。
这就是技术的价值。
当然，2dsphere也不是万能的。
它也有局限性。
比如，你查的范围太大，它也会慢。
所以，查询条件要写精准。
别搞那种“查找全国所有用户”的操作。
那是数据库杀手。
你要限定范围。
比如，查找半径5公里内的用户。
这样，索引才能发挥作用。
我见过有人，为了省事，把半径设成无限大。
结果服务器直接宕机。
重启了三次，才恢复。
心疼我的服务器。
总之，搞 bsondocument geo，心态要稳。
别慌。
先理清数据源。
再清洗数据。
然后选对索引。
最后，写查询语句。
每一步，都不能马虎。
这行水很深。
但也很有趣。
当你看到地图上，那些红点精准地落在你的目标位置时。
那种成就感，无可替代。
就像，终于找到了丢失已久的钥匙。
虽然过程曲折。
但结果，值得。
希望这篇碎碎念，能帮到你。
至少，让你少踩几个坑。
毕竟，头发已经够少了。
别再因为坐标问题，掉头发。
真的。
保重。
