昨天凌晨三点，我盯着代码编辑器里那行报错发呆，脑子里只有一个念头，这geo数据只有0行到底是怎么个事儿。本来以为换个API就能解决，结果折腾了一宿，头发掉了一把，最后发现居然是个标点符号的问题，真的想给自己两拳。

说实话做地理信息开发的人，谁没被这种看似简单实则要命的bug折磨过。上周接了个急单，甲方要实时在地图上显示几千个物流点的状态，结果前端传参过去，后端返回的数据集里，坐标字段全没了，表里干干净净，就剩个id，那geo数据只有0行简直成了我头顶挥之不去的幽灵。当时我第一反应是数据库抽风了，查了半天日志，发现SQL执行没问题，但返回的结果集确实是空的。这种时候真的比遇到内存泄漏还让人绝望，因为内存泄漏好歹能报个Error，这个静默失败，就像大冬天里的暖气管，外面看着热气腾腾，里面全是凉的。

为了排查这个问题我几乎把能试的办法都试了。先是怀疑数据源本身有问题，拿Postman直接请求数据库接口，居然有数据，几百条记录整整齐齐列在那。这时候我就开始怀疑是中间件处理层出了岔子，特别是那个专门负责把数据库记录转换成GeoJSON格式的自定义Filter。我翻了半天文档，又看了网上那些千篇一律的教程，都说要检查坐标格式对不对，是不是WGS84还是GCJ02没转换对。我也试了，加了一堆判断逻辑，只要坐标不在正常范围内就跳过，结果呢，还是geo数据只有0行，甚至比之前更离谱，连id都不见了。

就在我要把笔记本摔了的时候，我随手把其中一个返回的数据包复制到文本编辑器里，仔细看了一眼。当时我就愣住了，原来在JSON的结构里，有一个逗多了一个逗号。就在那个包含所有点坐标的对象数组末尾，多了一个,。这在JSON标准里是非法的，导致后面的解析器直接崩了，或者静默地丢弃了后面所有的数据。我就想问问那些写JSON解析库的大牛，你们能不能对这种低级错误报个醒目的Warning啊，搞个空结果返回，这不是纯纯折磨人吗？

其实这种geo数据只有0行的情况，很多时候真不是数据没了，而是你在某个环节把数据结构搞坏了。比如前端传参的时候，可能把数组传成了字符串，或者对象里嵌套层级太深，某一层少了个key。我记得之前还有朋友遇到过，是因为服务器时区设置不对，导致时间戳过滤条件把所有数据都滤掉了，最后看起来就像数据消失了一样。所以当你下次再遇到这种问题，别急着重写代码，先别怀疑人生，拿个在线的JSON校验工具，把你最终返回的那串字符丢进去看一看。有时候真理就藏在那些不起眼的符号里。

这次经历让我明白，写代码真的得细致点，尤其是处理这种地理位置数据，精度就是生命，格式就是规矩。如果你也遇到了类似的geo数据只有0行，千万别只盯着数据库看，多关注一下传输过程中的序列化反序列化环节。希望我的这点小教训能帮到你，少熬几宿的夜，多睡几个好觉。毕竟生活已经够粗糙了，代码里就别再留这种瑕疵了。】