Go连接Redis需用github.com/go-redis/redis/v8客户端，它原生支持GEOADD、GEORADIUS等命令及WITHCOORD、WITHDIST选项；避免使用redigo或v7及以前版本，因其GEO返回解析不一致；初始化时确保Addr正确且Redis版本≥3.2；GEOADD参数顺序为经度、纬度、成员名，范围分别为-180~+180和-90~+90；查询时需显式启用WithCoord(true)和WithDist(true)，单位优先用redis.Kilometer等常量；边界场景需结合逆地理编码、双坐标查询及坐标校验防穿透。
Go连接Redis并启用GEO命令支持
Go标准库不自带Redis GEO支持，必须用第三方客户端——github.com/go-redis/redis/v8 是当前最稳定的选择。它原生支持 GEOADD、GEORADIUS 等命令，且适配 Redis 6+ 的 WITHCOORD、WITHDIST 等选项。
别用 redigo 或老版本 go-redis（v7 及以前），它们对 GEO 返回结构的解析不一致，容易把 GEORADIUS 的多字段结果当成字符串切片处理，导致坐标解析失败。
- 初始化客户端时，确保
Addr指向真实 Redis 实例，不是本地127.0.0.1:6379就万事大吉——Docker 环境里常因网络模式错配连不上 - 调用前检查 Redis 版本：运行
redis-cli INFO server | grep redis_version，低于 3.2 的版本不支持 GEO 命令 - 连接后建议执行一次
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)+client.Ping(ctx).Err()，避免 GEO 请求时才发现连接断开
存入地理位置数据：注意经纬度顺序和精度
GEOADD 要求参数顺序是 经度 纬度 成员名，不是“纬度在前”。搞反会导致位置偏移上千公里——比如把北京（116.4°E, 39.9°N）写成 39.9 116.4 "beijing"，Redis 会把它当作南美洲某处。
经度范围是 -180 到 +180，纬度是 -90 到 +90。超出即报错 ERR invalid longitude,latitude。常见错误是前端传来的 GPS 坐标带了度分秒格式或含空格，没清洗就直传。
立即学习“go语言免费学习笔记（深入）”；
- 存语言学习点位时，建议用
struct{ Name string; Lon, Lat float64 }显式约束字段语义，避免变量名如x/y引发混淆 - 批量写入用
client.GeoAdd(ctx, "language:locations", &redis.GeoLocation{Longitude: 116.4, Latitude: 39.9, Name: "beijing-center"})，不要拼接多个GEOADD命令——单次调用可塞入上百个点，性能差一个数量级 - Redis GEO 内部用 GeoHash 编码，精度约 1 米（52 位），但实际应用中保留小数点后 6 位足够（
math.Round(lon*1e6)/1e6），避免浮点误差累积
查询附近语言学习点：控制返回字段与距离单位
GEORADIUS 默认返回成员名，但语言类应用通常需要名称、坐标、距离三者兼备。必须显式加 WithCoord(true) 和 WithDist(true)，否则 GeoLocation 结构体里的 Distance 和 Coordinates 都是零值。
单位默认是米（redis.Meter），但前端地图 SDK 常期望公里或英里——别在 Go 层做除法换算，直接传 redis.Kilometer 或 redis.Mile 更安全，避免 double 类型精度丢失。
- 半径设太大（如 10000 公里）会导致结果无序且慢，加
WithSort(true)和WithCount(20)限制数量和排序 - 用户坐标来自手机 GPS，可能有几十米漂移，用
GEORADIUSBYMEMBER查某个已存点（如“最近的教学中心”）比GEORADIUS更稳定 - 如果返回空切片，先确认 key 是否存在：
client.Exists(ctx, "language:locations").Val()，GEO 命令不会报错，但 key 不存在时静默返回空
边界情况处理：城市交界、跨国际日期线、缓存穿透
两个相邻城市（如深圳/东莞）的点位可能被同一半径覆盖，但业务上需区分归属地——Redis GEO 不提供行政区划信息，得靠外部服务（如高德逆地理编码 API）补全，不能只依赖距离排序。
国际日期线附近（如太平洋岛国）经度接近 ±180°，GeoHash 编码会跳变，GEORADIUS 可能漏掉本该命中的点。稳妥做法是：当用户经度接近 ±179° 时，主动查两次——一次用原坐标，一次把经度 ±360° 后再查，取并集。
- 缓存穿透风险：恶意请求经纬度为
0,0这种无效坐标，Redis 返回空，后端反复查 DB。加一层布隆过滤器或对坐标做基础校验（如lon >= -180 && lon = -90 && lat ） - 测试时别只用北京、上海等大城坐标，一定要试
Lon: -179.9, Lat: 0和Lon: 179.9, Lat: 0这类边缘值，看是否漏结果 - 生产环境开启 Redis 慢日志：
CONFIG SET slowlog-log-slower-than 10000（单位微秒），GEO 查询超 10ms 就要查是否没建索引——其实 GEO 自动建索引，慢大概率是半径过大或未设WITHCOUNT
