应采用“先粗筛、再精算”策略：用 geohash 空间分区预筛选，再调用 ext-geos 或 geoPHP 的 pointInPolygon 判断；围栏预加载至内存并支持 Redis PUB/SUB 热更新；注意坐标系一致、顶点顺序及协程安全。
Geofencing 检测该用什么算法，别直接上 haversine
Webman 是常用于高并发 API 服务的 PHP Swoole 框架，但 PHP 原生不带地理空间索引能力。直接对全部围栏逐个调用 haversine 计算距离，1000 个围栏 + 每秒 500 次定位上报，CPU 就会明显吃紧（实测 PHP-FPM 下单核 70%+）。真正高效的方案是「先粗筛、再精算」：用 geohash 做空间分区，把点和围栏按前缀归类，只对同 geohash 前缀（比如长度为 6）的围栏做距离判断。
推荐用 ext-geos 扩展（C 实现）或 geoPHP 库中的 Geometry::pointInPolygon，但注意：Webman 运行在 Swoole 协程中，geoPHP 的静态方法不是协程安全的，必须在 go() 内部调用或改用 ext-geos。
如何预加载围栏并支持热更新
围栏数据通常来自数据库或 Redis，但每次请求都查一次显然不行。Webman 的 onWorkerStart 是最合适的加载时机——每个 worker 进程启动时一次性加载全部围栏到内存，并构建 geohash → 围栏列表的映射数组。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 用
GeoHash::encode($lat, $lng, 6)生成 6 位 geohash 作为 key - 每个围栏多边形顶点缓存为
array[[lat1,lng1], [lat2,lng2], ...]，避免运行时解析 JSON - 若围栏需动态增删，不要用
filemtime轮询，改用 Redis 的PUB/SUB：管理后台发geofence:updated消息，worker 监听后 reload 自己的内存副本
pointInPolygon 判断失败的常见原因
很多开发者发现明明点在围栏内，pointInPolygon 却返回 false，问题往往不在算法本身，而在坐标顺序和边界处理：
- 多边形顶点必须按顺时针或逆时针闭合（首尾点可相同也可不同），乱序会导致射线法误判
- Webman 接收的 GPS 坐标可能是 WGS84（标准），但部分围栏数据导出时用了 GCJ-02 偏移，未纠偏会导致 100–500 米偏差
- PHP 浮点精度在跨纬度计算时可能引发临界点误判，建议对结果加
abs($distance) 的容差（单位：米） - 避免用
in_array()或array_search()查找点是否在顶点集合里——那是点集匹配，不是面内判断
性能压测时容易被忽略的协程陷阱
在 Webman 中用 go(function () { ... }) 并发检测多个设备位置时，看似能提升吞吐，但实际可能因共享内存结构导致竞争或 GC 压力激增：
- 所有围栏数据对象（如
Geofence实例）应设为只读，禁止在协程中修改其属性 - 避免在协程里 new 大量临时几何对象；改用对象池或复用
GEOSContext（如果用 ext-geos） - Swoole 5.0+ 默认开启
enable_coroutine => true，但ext-geos的部分函数（如GEOSPreparedGeom_create）不是协程安全的，需包裹在Swoole\Coroutine\Channel同步调用 - 日志打点别用
error_log()，它会阻塞协程；改用Log::channel('geofence')->info()配合异步写入驱动
复杂点在于：geohash 分辨率（长度）和围栏密度要动态匹配——城市中心用 7 位，郊区用 5 位，硬编码会导致某些区域漏检或过载。上线前务必用真实轨迹点集做离线回放验证，而不是只测单点。
