企业考勤地理围栏必须用geodesic（椭球面测地线距离）而非haversine，因后者在500米围栏下误差达1.5–2.5米，易导致误判；推荐使用github.com/paulmach/go.geo实现点-多边形判断与球面距离计算，并结合postgresql地理索引与redis缓存优化高频查询。
地理围栏判断用 haversine 还是 geodesic？
企业考勤对定位精度要求高，尤其在厂区边界、楼栋出入口等狭长或不规则区域，haversine 算法（球面距离）误差可达 0.3%–0.5%，在 500 米围栏半径下可能偏差 1.5–2.5 米——刚好跨出打卡范围。生产环境必须用 geodesic（椭球面测地线距离），Golang 生态推荐 github.com/paulmach/go.geo 或更轻量的 github.com/kellydunn/golang-geo。
实操建议：
-
go.geo.Point.Distance返回单位是米，直接与围栏半径（单位：米）比较，避免单位转换错误 - 不要自己实现
haversine公式——浮点运算顺序、弧度/角度混用、赤道/极地偏差都容易出错 - 若围栏是多边形（如园区轮廓），用
go.geo.Polygon.Contains判断点是否在内，而非只算中心点距离
Gin 中如何安全接收并校验 GPS 坐标？
用户手机上报的 latitude 和 longitude 经常含噪声、伪造或格式错误，直接传给地理计算会 panic 或误判。
实操建议：
- 用 Gin 的
ShouldBindQuery或ShouldBindJSON+ 自定义 struct tag 校验：type CheckInReq struct { Lat float64 `json:"lat" binding:"required,lt=90,gt=-90"` Lng float64 `json:"lng" binding:"required,lt=180,gt=-180"` } - 拒绝
lat=0&lng=0、lat=999等明显异常值——这些常来自未开启定位或模拟位置 App - 记录原始坐标、设备时间戳、网络类型（WiFi/4G）、
accuracy字段（Android 的location.getAccuracy()，iOS 的horizontalAccuracy），用于后续风控分析
围栏数据存在 Redis 还是 PostgreSQL？
考勤围栏通常数量少（几十到几百个）、更新频次低（按月调整）、但读取高频（每分钟数千次打卡请求）。PostgreSQL 支持地理索引（GiST + geography 类型），但 Gin 应用直连 PG 在高并发下易成瓶颈；Redis 没原生地理计算能力，但可存预计算结果。
实操建议：
- 围栏元数据（ID、名称、类型、生效时间）存 PostgreSQL，用
geography(Point,4326)字段存中心点，radius_m存半径；多边形围栏用geography(Polygon,4326) - 高频查询时，用
ST_DWithin（PG 内置函数）做索引加速：SELECT id FROM fences WHERE ST_DWithin(location::geography, ST_MakePoint($1, $2)::geography, $3) - 不要把整个围栏多边形 JSON 存 Redis 后用 Golang 计算——CPU 成瓶颈，且无法利用空间索引
为什么 time.Now().Unix() 不能当打卡时间戳？
客户端时间不可信，time.Now().Unix() 在服务端生成看似安全，但若服务器时钟未同步 NTP，或容器启动时系统时间滞后，会导致大量打卡被判定为“迟到”或“早退”。
实操建议：
- 所有时间戳统一用
time.Now().UTC().UnixMilli()（Go 1.19+），避免本地时区干扰 - 关键节点打日志时附带
time.Since(startTime)，监控时钟漂移：若单次请求中time.Now()相比上一次调用倒退 > 50ms，触发告警 - 与公司统一授时服务（如内部 NTP 或 Chrony）对齐，Docker 启动加
--network host或挂载宿主机/etc/chrony.conf
地理围栏逻辑本身不复杂，真正卡住上线的是坐标源可信度、时钟一致性、以及多边形边界在投影坐标系下的形变处理——这些细节没对齐，再准的算法也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
