用 github.com/twpayne/go-geom 的 containspoint 最稳，需确保多边形外环逆时针、坐标统一（wgs84 或投影），避免手写射线法导致边界错误。
Go 里怎么快速判断一个点是否在多边形围栏内
直接用 github.com/twpayne/go-geom + ContainsPoint 最稳，别手写射线法——边界情况（如点在边上、顶点重合、自相交多边形）极易出错。这个库底层用的是可靠的奇偶规则（even-odd rule），且已处理浮点误差和 degenerate cases。
常见错误现象：ContainsPoint 返回 false，但肉眼看明明在内部——大概率是坐标顺序反了（顺时针 vs 逆时针），或用了 WGS84 经纬度直接当平面坐标算（没投影）。
- 确保多边形环（
LinearRing）顶点按**逆时针顺序**排列（外环），否则结果可能翻转 - 如果围栏来自 GeoJSON 或地图平台导出，先调用
ring.Reverse()再判断，比猜顺序更可靠 - 经纬度必须转成平面坐标（如 Web Mercator EPSG:3857）再计算距离或面积；但「点是否在内」这一步，
ContainsPoint对经纬度也能工作——前提是所有点统一用 WGS84（geom.XY），且不涉及跨国际日期变更线的超大围栏
为什么不用 math/big 或自定义 float64 精度控制
地理围栏判断本质是几何关系，不是高精度科学计算。用 float64 完全够用：WGS84 下 1e-7 度 ≈ 1cm，go-geom 内部用 float64 并做了 epsilon 比较（比如 math.Abs(x) ），硬上 <code>math/big.Float 只会拖慢 10 倍以上，且毫无必要。
性能影响明显：实测 10 万次围栏判断，float64 版本约 12ms，big.Float（精度设为 256）超 180ms，还容易因舍入方向引发误判。
- 别在
ContainsPoint前对经纬度做 round 或 trunc——会把刚好在边上的点踢出去 - 如果真遇到「点在顶点上返回 false」，检查是否用了
ring.Coordinates()提取后又手动改了坐标值，导致精度丢失 - Web Mercator 投影下，高纬度地区形状会拉伸，但「是否包含」逻辑不变；真正要小心的是用投影后坐标去算真实距离——那得反解回经纬度
并发查围栏时 panic: concurrent map read and map write 怎么办
典型场景：HTTP handler 里反复调用 geom.NewPolygon 构造围栏，但把 Polygon 实例存在全局 map 里被多 goroutine 直接读——Polygon 不是线程安全的，它内部缓存了 bounding box，写操作（如首次调用 BoundingBox()）会触发 map 修改。
解决方式很简单：围栏对象只构造一次，然后用 geom.Polygon.Clone() 或直接传值（Polygon 是 struct，非指针）；或者更推荐——所有围栏初始化完就调用一次 BoundingBox()，让它完成内部缓存，之后只读就没问题。
- 别把
*geom.Polygon存 map 后多个 goroutine 直接调ContainsPoint - 用
sync.Pool缓存geom.Polygon实例反而画蛇添足；struct 值拷贝开销极小，clone 也只深拷贝坐标切片 - 如果围栏动态更新频繁，用
atomic.Value存最新geom.Polygon，每次更新Store新实例，读时Load后直接用，零锁
GeoJSON 围栏解析后 ContainsPoint 总是 false
八成是坐标维度搞反了：GeoJSON 规定 [longitude, latitude]（x,y），但很多人习惯先写 lat 再写 lng，解析后点变成 (lat, lng)，而多边形顶点却是 (lng, lat)，坐标系错位导致全部误判。
用 github.com/paulmach/go.geojson 解析时，它默认按 GeoJSON 标准处理，但你的原始数据如果来自百度地图、高德或某些旧系统，可能本身就是 [lat, lng] 顺序。
- 解析完立刻打日志：
fmt.Printf("point: %+v, ring[0]: %+v", p, ring.Coordinates()[0])，对比看 x/y 是否符合「经度在 -180~180、纬度在 -90~90」 - 如果发现 point.x 是 39.9（明显是纬度），说明你该 swap：
p = geom.Coord{p[1], p[0]} - 别依赖「看起来像不像」——杭州经纬度接近 (120.1, 30.2)，但乌鲁木齐是 (87.6, 43.8)，单看数字无法判断顺序
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
