昨天有个刚入行的小兄弟跑来问我，说在写前端定位功能的时候，看到代码里一堆geo开头的变量，心里直打鼓，怕写错了被领导骂。这其实挺正常的，毕竟现在LBS（基于位置的服务）这么火，不管是做外卖、打车还是社交软件，地理位置都是核心。
很多人对geo前缀的意思理解得不够透彻，总觉得就是跟地图有关，于是想当然地命名变量。比如把用户当前的经纬度叫成userLocation，或者把地图中心点叫成mapCenter。这种做法在小型项目里可能没事，但一旦项目变大，代码量上来，维护起来简直就是灾难。
我见过一个真实的案例。有个团队做社区团购小程序，前期为了赶进度，开发者随意命名变量。有的叫lat，有的叫latitude，还有的叫geo_lat。等到后期要接入新的地图服务商，或者要做历史轨迹回放功能时，前端和后端对接数据，愣是对了半天都没对上。
为什么会出现这种混乱？根本原因就是对geo前缀的意思缺乏统一认知。在W3C的Geolocation API标准里，geo通常代表地理空间数据。所以，凡是跟地理位置强相关的对象、属性或方法，加上geo前缀，能让其他开发者一眼看出这玩意儿是干嘛的。
比如，获取地理位置的对象，命名为geoLocation比location更准确，因为location在JS里通常指浏览器窗口的位置。再比如，地理围栏（Geofence）相关的配置，写成geoFenceConfig，比写locationFenceConfig要专业得多，也符合行业惯例。
这里有个小细节要注意。很多人会混淆geo前缀和lat/lng前缀。其实它们并不冲突。geo前缀更多用于标识“地理相关”这个大类，而具体的经纬度可以用lat/lng。比如geoPosition对象里包含lat和lng属性。这样结构清晰，逻辑也顺。
我有个朋友，之前在一个电商项目里，因为没搞懂geo前缀的意思，把用户的收货地址缓存写成了userAddressGeo。结果后端接口返回的是字符串格式的地址，前端解析时一直报错。查了三天bug，最后发现是数据类型不匹配。要是当时规范一点，写成userAddressInfo，可能半天就解决了。
所以，掌握geo前缀的意思，不仅仅是为了代码好看，更是为了团队协作的效率。当你在代码里看到geoMarker，就知道这是地图上的标记点；看到geoRadius，就知道这是定位的半径范围。这种语义化的命名，能极大降低沟通成本。
当然，也不是所有带geo的都要这么干。如果是普通的字符串变量，比如用户输入的“北京”，就没必要叫geoBeijing。geo前缀应该留给那些具有空间属性、需要经纬度支撑的数据结构。
总结一下，写代码就像说话，要让人听得懂。搞懂geo前缀的意思，让你的变量名会“说话”。别为了省事随便起名字，后期改起来哭都来不及。记住，规范不是束缚，而是保护。
希望这篇文章能帮到那些在定位功能开发中迷茫的朋友。如果你也在纠结变量命名，不妨试试加上geo前缀，看看代码是不是清爽了不少。毕竟，代码是写给人看的，顺便给机器执行。
本文关键词：geo前缀的意思
