float64在经纬度计算中完全够用，因WGS84下1e-7度≈1厘米，而float64机器精度2.2e-16可分辨约0.01毫米，远超实际需求，主流地理库均采用并内置epsilon比较逻辑。
直接用 float64 就够了，别碰 math/big 或自定义高精度浮点类型——地理计算不是金融对账，要的是几何关系正确性，不是小数点后 50 位。
为什么 float64 在经纬度计算中完全够用
WGS84 坐标系下，1e-7 度 ≈ 1 cm，而 float64 的机器精度（ε ≈ 2.2e-16）在经度方向可分辨约 0.01 mm，在实用场景中远超需求。所有主流地理库（如 github.com/twpayne/go-geom、mongo-go-driver、Redis GEO）内部都用 float64，且已内置 epsilon 比较逻辑（比如 math.Abs(x) ）来处理浮点误差。
常见错误现象：ContainsPoint 返回 false，但肉眼看明显在多边形内——大概率是坐标顺序反了，或用了未投影的 WGS84 坐标去算面积/距离，而不是精度问题。
- 别对经纬度做
math.Round或trunc后再传入几何函数：会把刚好落在边上的点踢出去 - 从 GeoJSON 或地图平台导出的多边形，顶点顺序不保证逆时针；用前先调
ring.Reverse() - 跨国际日期变更线的大围栏（如覆盖太平洋全域）才需考虑投影；普通城市级围栏直接用 WGS84
geom.XY安全
什么时候必须控制输出格式，而不是计算精度
真正需要“精度控制”的地方，往往不在计算过程，而在**序列化输出**：比如把经纬度塞进 JSON、写入日志、拼 SQL 或发给前端渲染。这时候 float64 默认转字符串可能变成科学计数法（"4e+01"），或带一堆无意义尾零（"39.908700000000004"），导致下游解析失败或 UI 显示异常。
✅ 正确做法是用 strconv.FormatFloat(x, 'f', -1, 64)：
-
'f'强制固定小数点表示，禁用指数 - 精度设为
-1：让 Go 自动选择最简、无损的十进制表示（保留所有必要小数位，不补零） - 显式指定
64位，避免因类型推断出错
示例：strconv.FormatFloat(39.9087, 'f', -1, 64) → "39.9087"，strconv.FormatFloat(-0.000000123, 'f', -1, 64) → "-0.000000123"。
并发查围栏时 panic: concurrent map read and map write 怎么办
典型场景：HTTP handler 中反复构造 geom.Polygon 并存进全局 map[string]geom.Polygon，多个 goroutine 直接读这个 map —— Polygon 是 struct，但其内部缓存了 bounding box，首次调用 BoundingBox() 会触发非线程安全的 map 写操作。
解决方式很轻量：
- 围栏初始化完成后，立刻调一次
polygon.BoundingBox()，让它完成内部缓存；之后只读就安全 - 或者改用值传递：每次查询都传
polygon.Clone()或直接传 struct 值（Polygon不大，拷贝开销可忽略） - 绝对不要把
*geom.Polygon存进全局 map 并多 goroutine 共享指针
最容易被忽略的一点：精度问题几乎从不来自 float64 本身，而是来自坐标系误用（WGS84 当平面坐标算）、环顺序错误、未闭合多边形、或输出时格式失控。先盯死这几处，比折腾高精度计算实在得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
