Go连接Redis启用GEO需Redis服务端≥3.2且连通，客户端用github.com/go-redis/redis/v9；GEOADD必须经度在前、纬度在后，范围合规；GEORADIUS需显式指定单位（m/km/mi/ft）、WITHDIST、SORT和COUNT；GEORADIUSBYMEMBER更安全，复用已存坐标避免精度丢失。
Go连接Redis并启用地理空间功能需要什么前提
Redis的地理空间（GEO）命令依赖服务端版本 ≥ 3.2，且默认开启，无需额外配置。但Go客户端必须支持GEOADD、GEORADIUS等命令——github.com/go-redis/redis/v9完全支持，而老版本v8或第三方库如redigo需手动封装命令，容易出错。
- 确保Redis服务运行且可访问，用
redis-cli ping确认连通性 - Go项目中引入
github.com/go-redis/redis/v9，不是v8或redigo - 初始化客户端时，
Addr字段要写对，例如"localhost:6379"，密码非空时必须设Password - 不要尝试用
SET存经纬度字符串来模拟GEO——Redis GEO底层是geohash+有序集合，手动实现无法使用GEORADIUS
用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 - 一个key下可存多个位置，例如用
"venues"作为key，成员名用业务ID：client.GeoAdd(ctx, "venues", &redis.GeoLocation{Longitude: 116.3975, Latitude: 39.9087, Name: "beijing-station"})
GEORADIUS查附近时，单位、排序和边界怎么控制
GEORADIUS默认返回无序结果，且不保证距离精确到米级——它基于geohash格网匹配，对跨格网的近邻可能遗漏。实际使用必须显式指定WITHDIST、SORT和COUNT。
- 单位只能是
m（米）、km、mi（英里）、ft（英尺），写错如"M"或"meter"会报ERR unsupported unit - 要按距离由近到远排，必须加
SORT BY DIST，否则顺序随机 - 不设
COUNT可能返回成百上千条，拖慢响应；建议始终限制，例如COUNT 20 - 示例调用：
client.GeoRadius(ctx, "venues", 116.3975, 39.9087, &redis.GeoRadiusQuery{Radius: 5, Unit: "km", WithDist: true, Sort: "ASC", Count: 10})
为什么GEORADIUSBYMEMBER比直接用经纬度更安全
当查询“某个已存地点周边”时，用GEORADIUSBYMEMBER可避免重复传入可能出错的经纬度值。比如用户点击“查看北京站附近咖啡馆”，后端若从数据库读出北京站坐标再调GEORADIUS，中间经历浮点解析、传输、精度丢失，而GEORADIUSBYMEMBER直接复用Redis中已校验过的坐标。
立即学习“go语言免费学习笔记（深入）”；
- 成员名（
Name）必须严格匹配GEOADD时写的字符串，区分大小写、空格、编码 - 若成员不存在，命令返回空结果，不会报错，需在Go里检查
len(results) == 0而非panic - 它和
GEORADIUS参数结构一致，只是把经纬度换成member字段：client.GeoRadiusByMember(ctx, "venues", "beijing-station", &redis.GeoRadiusQuery{Radius: 1, Unit: "km", Count: 5})
Redis GEO不是万能地理引擎，不支持多边形、路径规划或高精度测地线距离。真有复杂需求，得接PostGIS或专用服务——但对“附近门店”“活动签到范围”这类场景，它轻量、快、够用。别在GEOADD时手抖把经纬度写反，也别忘了COUNT限流。
