最稳妥是在模型中自定义isInFence()方法，使用Haversine公式计算距离并结合GeoJSON解析与射线法判断多边形围栏，配合经纬度范围粗筛和缓存优化。
ThinkPHP 模型里怎么加地理围栏判断逻辑
直接在模型里写 isInFence() 这类方法最稳妥，别指望框架自带——ThinkPHP 没提供地理围栏原生支持，硬套 scope 或 accessor 容易漏掉坐标精度、投影转换等关键环节。
常见错误是把经纬度当平面坐标算距离，结果城市级围栏偏差几公里；或者用 sqrt((x1-x2)^2 + (y1-y2)^2) 简单算，没走 Haversine 公式，高纬度地区误差爆炸。
- 用
haversineDistance()函数（自己封装或引入轻量库如geophp），输入单位必须是度，输出单位统一为米 - 围栏数据建议存在独立表（如
fences），模型关联时用belongsTo，别塞进用户表加一堆fence_*字段 - 查询时避免全表计算：先用
WHERE lng BETWEEN ? AND ? AND lat BETWEEN ? AND ?做粗筛，再对候选集精算
自定义模型行为（Behavior）怎么注册并生效
ThinkPHP 6+ 的行为机制本质是事件监听器，不是“插件式挂载”，app\behavior\FenceCheck 这类类名本身不触发任何逻辑，必须手动绑定到 model.after_find 或 model.before_write 等具体事件。
容易踩的坑：在 config/event.php 里只写了类名，没指定事件名；或者行为里调用了 $this->app 但没在构造函数注入依赖，运行时报 Call to a member function on null。
立即学习“PHP免费学习笔记（深入）”；
- 注册方式必须是：
'model.after_find' => [app\behavior\FenceCheck::class]，不能只写FenceCheck::class - 行为内访问模型数据用
$params['data']（查后）或$params['query']（查前），别直接$this->data - 若需异步校验（如围栏变更通知），行为里别写阻塞逻辑，改用
event('fence.changed', $data)触发后续监听
GeoJSON 格式围栏数据怎么解析并用于判断
别手写正则拆 Polygon 坐标，ThinkPHP 没内置 GeoJSON 解析器，直接上 json_decode($geojson, true) 后递归取 ['coordinates'][0] 即可，但要注意坐标顺序：GeoJSON 是 [lng, lat]，而国内地图 API（如高德、腾讯）常用 [lat, lng]，反了就全错。
性能影响明显：每次请求都 file_get_contents() 读 GeoJSON 文件？不如启动时缓存到 think\Cache，键名用围栏 ID + 更新时间戳组合，过期时间设 1 小时足够。
- 多边形判断用射线法（Ray Casting），别用面积法——后者对自相交多边形结果不可靠
- 缓存失效时机：围栏编辑后主动
Cache::delete('fence_'.$id)，别依赖自动过期 - 前端传来的点坐标，务必在服务端二次校验范围：
abs($lng) ，防脏数据炸掉计算
为什么不用数据库空间扩展（如 MySQL GIS）
因为大多数 ThinkPHP 项目跑在共享主机或低配云服务器上，MySQL 缺失 ST_Contains() 或 ST_Distance_Sphere() 函数，强行启用会报 FUNCTION xxx does not exist；即使有，TP 的 Query Builder 对空间函数支持极弱，写 whereRaw('ST_Contains(fence_shape, POINT(?,?))', [$lng, $lat]) 很容易被自动转义搞崩。
更现实的问题是：GIS 索引（R-Tree）在 TP 的 ORM 层几乎无法控制，with(['fence']) 关联查询时没法让数据库走空间索引，最终还是全表扫描。
- 真要用 GIS，绕过 ORM 直接
Db::query()写原生 SQL，并确保字段类型是GEOMETRY，不是TEXT - PostgreSQL + PostGIS 组合虽强，但部署成本和运维复杂度远超业务需要，中小项目优先选纯 PHP 实现
- 如果围栏数量稳定在百级以内，内存预加载所有围栏多边形顶点，比每次查库+计算快 3~5 倍
地理围栏真正的复杂点不在代码怎么写，而在坐标系混用、时序一致性（比如围栏更新了但缓存没清）、以及边界情况处理（跨国际日期变更线、极点附近）。这些地方一漏，线上问题很难复现。
