Go语言不控制地理坐标精度，关键在于传给Redis的float64值是否合法、未被截断或四舍五入；Redis GEO命令严格要求经度在前（-180.0~180.0）、纬度在后（-90.0~90.0），顺序错误或越界将导致严重偏移或报错；Redis内部自动截断至小数点后7位，无需手动格式化；GEORADIUS需显式指定单位、WithDist、Sort和Count；优先使用GEORADIUSBYMEMBER复用已存坐标以减少精度漂移；展示、计算、索引对精度要求本质不同。
Go语言本身不控制地理坐标的“业务精度”，真正起作用的是你传给Redis的float64值是否在合法范围内、是否被意外截断或四舍五入——而Redis GEO命令会默默接受并存储它，哪怕你传的是116.39750000000001这种带IEEE 754尾差的值。
GeoAdd传参时经纬度顺序和范围必须严格校验
Redis要求GEOADD参数顺序是经度 longitude在前、纬度 latitude在后，和常见GIS习惯（lat, lng）相反。传反会导致位置偏移数千公里，且无任何报错提示。
- 经度必须在
-180.0到180.0之间，纬度必须在-90.0到90.0之间；超出直接返回ERR invalid longitude, latitude - Go中用
float64传入即可，Redis内部自动截断到小数点后7位（约1米精度），无需手动math.Round或toFixed - 结构体字段命名建议用
Longitude/Latitude而非Lng/Lat，避免团队协作时混淆顺序
不要对float64坐标做字符串格式化再解析
有人为“保留两位小数”写fmt.Sprintf("%.2f", lng)再strconv.ParseFloat，这反而引入新误差：字符串格式化本身会四舍五入，且解析过程可能丢失原始精度。
-
116.39749999999999经格式化变成"116.40"，再解析成float64就不再是原值 - Redis GEO实际只用到小数点后7位，你传
116.3975和116.39750000000001效果完全一样 - 若需日志/调试显示简洁，用
fmt.Printf("%.6f", lng)即可；但生产代码中直接传原始float64最安全
GEORADIUS查询时单位拼写和排序必须显式指定
GEORADIUS默认不返回距离、不排序、不限数量，看似简单，实则极易踩坑。
- 单位只能是
"m"、"km"、"mi"、"ft"，写成"M"或"meter"会报ERR unsupported unit - 不加
Sort: "ASC"，结果顺序随机，无法保证“最近的在前” - 不设
Count，可能一次返回上千条，拖慢响应甚至OOM；建议始终限制，如Count: 50 - 务必加
WithDist: true，否则无法知道每个结果离中心多远
用GEORADIUSBYMEMBER替代重复传经纬度更可靠
当你要查“某个已知地点周边”（比如“北京站附近3公里内的充电桩”），优先用GEORADIUSBYMEMBER，而不是从数据库读出坐标再调GEORADIUS。
- 避免浮点数在数据库→Go→Redis链路中多次解析/传输，减少精度漂移风险
- Redis中存的坐标已在
GEOADD阶段做过范围校验，复用它比重新构造更可信 - 调用时只需
client.GeoRadiusByMember(ctx, "venues", "beijing-station", &redis.GeoRadiusQuery{Radius: 3, Unit: "km", WithDist: true, Sort: "ASC", Count: 20}) - 注意：
member必须已存在，否则返回空；上线逻辑里要确保先GeoAdd自身节点
真正难的不是“怎么传坐标”，而是想清楚：这个坐标是用于展示、用于计算、还是用于索引？展示可以容忍%.6f，计算必须用原始float64，索引则依赖Redis内部geohash格网——三者对“精度”的定义根本不同。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
