Golang用Haversine公式算经纬距离方法

Go中应手写haversine公式计算地理距离：输入经纬度需转弧度，用6371km地球半径，固定(lat1,lng1,lat2,lng2)顺序；对asin输入做[-1,1]截断防panic；统一用float64防精度误差；手动处理经度跨180°及非法坐标。

Go 里直接用 haversine 公式算距离，别碰第三方库

标准库没提供地理距离函数，但 haversine 公式就十几行，自己写比引入 github.com/kellydunn/golang-geo 或 github.com/paulmach/go.geo 更轻、更可控。第三方库常带坐标系转换、缓存、多边形支持等你根本不用的功能，反而增加维护负担和精度疑点。

实操建议：

• 所有经纬度必须转为弧度再代入公式 —— math.Sin、math.Cos 等函数只认弧度，用 deg * math.Pi / 180 转换
• 地球半径统一用 6371 km（平均值），别用 6378（赤道）或 6357（极地），除非你明确在做高精测绘
• 输入坐标顺序固定为 (lat1, lng1, lat2, lng2)，纬度在前、经度在后，和 GeoJSON、大多数 API 一致；反了会算出荒谬结果

为什么 math.Asin 和 math.Sqrt 容易 panic

公式里有 math.Asin(…)，而它的参数必须在 [-1, 1] 区间内。浮点误差可能导致计算结果略大于 1（比如 1.0000000000000002），触发 math.Asin 返回 NaN，后续再用这个值参与运算，最终距离变成 NaN 或负数。

实操建议：

• 对 math.Asin 的输入做安全截断：math.Max(-1, math.Min(1, x))
• 避免用 math.Atan2 替代 —— 虽然它不 panic，但会掩盖数值异常，导致距离偏差悄无声息
• 上线前用极端坐标测试：比如两极点 (90, 0) 和 (-90, 0)，应得约 20015 km；赤道对跖点 (0, 0) 和 (0, 180) 应得约 20037 km

float64 足够，别用 float32 算经纬度距离

纬度每 0.0001° ≈ 11 m，经度随纬度变化，但在中纬度也接近这个量级。用 float32 表示经纬度时，有效位数仅约 7 位十进制数字，116.3912345 这种常见经度会被截断成 116.391235，单点误差就可能超 1 米；两点叠加后，距离误差轻松破 5 米。

实操建议：

• 所有中间变量、参数、返回值一律用 float64
• 从数据库或 HTTP 请求拿到的 float32 值，立刻转 float64 再参与计算，别在函数签名里妥协
• 性能无实质影响 —— 在现代 CPU 上，float64 加减乘除和 float32 几乎一样快；瓶颈永远在 math.Sin/math.Cos 这类超越函数上

单位、精度、边界情况全靠自己兜底

Go 没有类型系统约束“这是米”还是“这是千米”，也不会自动处理 lng 跨 180° 经线（比如 179° 和 -179° 实际只差 2°，但裸算差值是 358°）。这些都得手动防。

实操建议：

• 经度标准化：用 ((lng + 180) % 360) - 180 把任意经度映射到 [-180, 180) 范围
• 距离单位明确写死：函数返回 float64，文档/注释必须写清是“米”还是“千米”；推荐返回米，和 PostGIS、Google Maps Distance Matrix 对齐
• 空值或非法坐标（如 lat=95）不尝试容错计算，直接 return 0, errors.New("invalid latitude") —— 模糊处理只会让 bug 更难定位

最麻烦的从来不是公式本身，而是怎么把用户随手扔进来的 "39.9042,116.4074" 字符串，和数据库里存的 NULL、-999、"N/A" 一起，稳稳落到那个 math.Sin 的参数里。