geoadd参数顺序错误、坐标系不匹配、georadius单位误用是三大高频事故源；必须严格遵循lng,lat顺序、wgs84坐标系、小写单位（m/km/ft/mi），并端到端验证。
GEOADD 参数顺序写反是最高频的线上事故，没有之一——它不会报错，但所有查询结果都会偏移上万公里。
Go 调用 GeoAdd 时经纬度必须是 lng, lat 顺序
Redis 的 GEOADD 命令底层要求「经度在前、纬度在后」，而 Go 客户端（如 github.com/redis/go-redis/v9）完全信任你传入的参数，不做合法性校验。一旦传成 lat, lng，坐标就飞到南美内陆或南极，且无法通过日志或错误感知。
- 错误写法：
client.GeoAdd(ctx, "user:geo", 31.205593, 121.446617, "u123")→ 把上海纬度当经度存了 - 正确写法：
client.GeoAdd(ctx, "user:geo", 121.446617, 31.205593, "u123") - 批量添加更稳：
client.GeoAdd(ctx, "user:geo", &redis.GeoLocation{Longitude: 121.446617, Latitude: 31.205593, Name: "u123"}, ...)，避免循环发单条命令带来的网络与性能损耗 - 注意范围：
Longitude必须 ∈ [-180, 180]，Latitude必须 ∈ [-90, 90]；Redis 对纬度还额外限制为 ±85.05112878（WGS84 投影上限），超限会返回ERR invalid longitude, latitude
GeoRadius 查询时单位和精度参数不能省略
调用 GeoRadius 不填 Unit 或乱填单位（比如写 "KM" 或 "kilometers"），会导致 Redis 返回空结果或距离计算错乱——它只认小写 "m"、"km"、"ft"、"mi" 四种。
- 必须显式指定：
&redis.GeoRadiusQuery{Radius: 5, Unit: "km", WithCoord: true, WithDist: true} -
WithCoord和WithDist是布尔开关，不是字符串参数；不设WithCoord就拿不到经纬度，不设WithDist就不知道谁近谁远 - 别自己解 GeoHash 算距离：Go 库里的
geohash.Encode(39.9086, 116.3974)要求是lat, lng顺序（和 Redis 相反！），但GeoRadius已封装 Haversine 球面距离计算，直接用就行
从高德/百度地图取坐标后必须纠偏再进 Redis
Redis GEO 只支持 WGS84 坐标系，而国内主流地图 SDK（高德、百度）返回的是 GCJ-02 或 BD-09 坐标系，未经转换直接存入会导致位置偏差几百米——这不是精度问题，是系统性偏移。
- 前端
Geolocation API返回的coords.longitude/coords.latitude是 WGS84，可直存 - 高德 SDK 的
AMap.LngLat默认是 GCJ-02，需调用gcj02towgs84(lng, lat)转换（可用开源库如github.com/tidwall/gjson配合纠偏表，或调用服务端转换接口） - 百度坐标需先转 GCJ-02，再转 WGS84；跳过中间步会放大误差
- 验证方式：用已知 WGS84 坐标（如天安门：116.3974, 39.9086）查
GEORADIUS，若返回为空或距离异常，大概率是坐标系没对齐
最危险的不是报错，而是静默错位——参数顺序、坐标系、单位这三处全靠人工核对，没有运行时兜底。上线前务必用已知坐标的点做端到端验证，别只测“能存进去”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
