最安全方式是用db::raw()包裹整个haversine表达式，经纬度字段加反引号如lat、lng，中心坐标通过绑定参数传入，严禁字符串拼接。
ThinkPHP 6 的 whereRaw 怎么安全写经纬度距离公式
直接在 whereRaw 里拼 SQL 计算 Haversine 距离，是最轻量、最可控的方式，但容易因变量未转义或字段名冲突导致 SQL 报错或结果错误。
- 必须用
DB::raw()包裹整个计算表达式，不能只包参数；否则 TP 会把括号里的内容当字符串字面量处理 - 经纬度字段名要加反引号，比如
`lat`和`lng`，避免和 MySQL 关键字（如order）或保留字冲突 - 用户传入的中心点坐标必须用
DB::raw()+ 绑定参数方式传入，禁止字符串拼接：whereRaw('ST_DISTANCE(POINT(?, ?), POINT(`lng`, `lat`)) 不可靠（MySQL 5.7+ 才支持 <code>ST_DISTANCE，且单位是米，精度依赖 SRID） - 更通用的做法是手写 Haversine 公式：
whereRaw('6371 * acos(cos(radians(?)) * cos(radians(`lat`)) * cos(radians(`lng`) - radians(?)) + sin(radians(?)) * sin(radians(`lat`)))
为什么别用 Db::query() 直接执行原生 SQL
看似自由，实则绕过了 TP 的查询构建器机制，丢失了连接复用、日志追踪、异常统一处理等能力，调试时连哪条 SQL 出错都难定位。
- 如果用了
Db::query()，后续想加软删除条件、租户隔离字段、或做分页，就得自己手动拼，极易漏掉 - TP 的
with关联预加载、scope查询作用域、macro自定义方法全部失效 - 更关键的是：MySQL 8.0.20+ 对
acos等函数的 NULL 输入返回 NULL，而Db::query()不会自动帮你过滤lat/lng为空的记录，结果集可能混入无效数据
封装成模型作用域（scopeNearby）要注意什么
把距离逻辑收进模型方法看着整洁，但一不留神就变成“伪封装”——参数硬编码、单位混淆、索引失效。
- 作用域函数签名建议带单位参数：
scopeNearby($query, $lat, $lng, $radius, $unit = 'km')，避免默认按公里算却传了米值 - 务必在作用域开头加
$query->whereNotNull(['lat', 'lng'])，防止acos计算时遇到 NULL 导致整行被排除（MySQL 默认行为） - 不要在作用域里调用
paginate()，分页应由调用方控制；否则无法和其它 where 条件组合，也违背单一职责 - 如果表数据量大（>10 万），这个查询必然全表扫描——TP 不会自动帮你建地理空间索引，得手动在数据库加
SPATIAL INDEX或改用POINT字段 +ST_Distance_Sphere
TP 6.3+ 能否用 think-spatial 扩展替代手写
可以，但不推荐用于简单距离筛选场景。它把事情变重了，而且和 TP 主干版本兼容性差，更新滞后。
-
think-spatial强制要求字段类型为POINT，意味着你要改表结构、迁移历史数据，线上环境风险高 - 它封装的
distanceSphere方法底层仍调用ST_Distance_Sphere，但参数顺序易错：distanceSphere('location', [116.4, 39.9])中数组是[lng, lat]，和常见 API（如高德）的[lat, lng]相反 - 扩展没处理边界情况：比如用户传了非法坐标（
lat > 90），它不会提前校验，而是让 MySQL 报Invalid GIS data provided错误，堆栈里看不到具体哪条数据出问题
实际用下来，最稳的路还是老老实实用 whereRaw + Haversine，把坐标校验、空值过滤、单位换算这些事放在 Service 层做清楚。地理计算本身不复杂，复杂的是怎么让它在 TP 的生命周期里不掉链子——尤其当你要加缓存、导出、或者对接小程序地图组件的时候。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
