今天又是被百度地图API气得想摔键盘的一天。

本来兴致勃勃想做个附近的人功能。

结果调试了一整天，全是报错。

核心错误就俩字：无效。

后来查了半天文档，终于找到原因。

其实就是因为参数传的格式不对。

很多人遇到geo不能计算，都是因为经纬度写反了。

别笑，我也犯过这低级错误。

Latitude是纬度，Longitude是经度。

很多人习惯性先写经度，再写纬度。

这在很多坐标系里完全是两码事。

我有个做LBS创业的朋友。

上个月搞了个团购小程序。

因为没注意坐标顺序，导致所有定位都偏到海里去了。

用户投诉都要把客服骂死。

后来花了好几天排查，才发现是这个问题。

数据偏差达到了几十公里，离谱。

除了坐标顺序，还有坐标系的问题。

这点真的超级容易踩坑。

GCJ-02和WGS-84完全不通用。

如果你用的是高德或百度的数据。

直接拿去算距离，那肯定报错。

这俩个坐标系本身就不一样。

一个是国家测绘局加密过的。

另一个是国际通用的GPS标准。

直接混用，就是典型的geo不能计算原因。

我之前帮一个做物流的老哥修bug。

他那边系统用的是腾讯的地图SDK。

但是后台数据库存的是纯GPS坐标。

结果每次算路径，都提示失败。

查了半天日志，发现是坐标系没转换。

加了个转换插件后，立马就顺了。

这种问题，光看文档还真不一定能看出来。

得靠实打实的踩坑经验。

还有个细节，就是坐标系类型声明。

有些API需要你显式声明坐标系。

比如bd09ll或者gcj02。

如果你不声明，默认可能按wgs84处理。

这一弄，偏差又是几百米往上走。

对于做导航类产品的，这简直要命。

所以我建议在调API前。

先确认清楚你手头数据的源头。

是设备直接获取的GPS？

还是从某个特定地图服务获取的？

千万别想当然。

另外，精度也是个坑。

有时候你传的数值精度太高或太低。

也会导致底层库处理溢出或截断。

虽然这种情况比较少见。

但也遇到过类似的案例。

有个开发者传了保留20位小数的经纬度。

直接导致浮点数计算出错。

删掉几位小数就正常了。

所以，数据清洗真的很重要。

不要相信用户输入的“完美数据”。

一定要做标准化处理。

统一转成GCJ-02或者BD-09。

再扔给算法去计算。

这样能避开90%的geo不能计算问题。

最后总结几点建议吧。

第一，核对坐标顺序。

第二，统一坐标系转换。

第三，检查API参数声明。

第四，做必要的数据清洗。

第五，多造异常数据测试。

别等到上线了再后悔。

那时候出线上事故，加班都得加到秃头。

希望踩过的坑，你们都能避开。

少走弯路，早点下班。

这才是正经事。

本文关键词：geo不能计算