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 更轻、更可控。第三方库常带坐标系转换、缓存、多边形支持等你根本不用的功能，反而增加维护负担和精度疑点。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有经纬度必须转为弧度再代入公式 ——
math.Sin、math.Cos等函数只认弧度，用deg * math.Pi / 180转换 - 地球半径统一用
6371km（平均值），别用6378（赤道）或6357（极地），除非你明确在做高精测绘 - 输入坐标顺序固定为
(lat1, lng1, lat2, lng2)，纬度在前、经度在后，和 GeoJSON、大多数 API 一致；反了会算出荒谬结果
为什么 math.Asin 和 math.Sqrt 容易 panic
公式里有 math.Asin(…)，而它的参数必须在 [-1, 1] 区间内。浮点误差可能导致计算结果略大于 1（比如 1.0000000000000002），触发 math.Asin 返回 NaN，后续再用这个值参与运算，最终距离变成 NaN 或负数。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对
math.Asin的输入做安全截断：math.Max(-1, math.Min(1, x)) - 避免用
math.Atan2替代 —— 虽然它不 panic，但会掩盖数值异常，导致距离偏差悄无声息 - 上线前用极端坐标测试：比如两极点
(90, 0)和(-90, 0)，应得约20015km；赤道对跖点(0, 0)和(0, 180)应得约20037km
float64 足够，别用 float32 算经纬度距离
纬度每 0.0001° ≈ 11 m，经度随纬度变化，但在中纬度也接近这个量级。用 float32 表示经纬度时，有效位数仅约 7 位十进制数字，116.3912345 这种常见经度会被截断成 116.391235，单点误差就可能超 1 米；两点叠加后，距离误差轻松破 5 米。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有中间变量、参数、返回值一律用
float64 - 从数据库或 HTTP 请求拿到的
float32值，立刻转float64再参与计算，别在函数签名里妥协 - 性能无实质影响 —— 在现代 CPU 上，
float64加减乘除和float32几乎一样快；瓶颈永远在math.Sin/math.Cos这类超越函数上
单位、精度、边界情况全靠自己兜底
Go 没有类型系统约束“这是米”还是“这是千米”，也不会自动处理 lng 跨 180° 经线（比如 179° 和 -179° 实际只差 2°，但裸算差值是 358°）。这些都得手动防。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 经度标准化：用
((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 的参数里。
