st_dwithin更可靠，因它自动适配空间参考系（srid）：对地理坐标系（如4326）默认用球面距离（米），避免手动用st_distance误算平面距离导致误差。
ST_DWithin 为什么比手动计算距离更可靠
直接用 ST_DWithin 判断两点是否在指定距离内，比先算 ST_Distance 再比较更安全——它能自动选择合适的空间参考系（SRID），避免在地理坐标（如 WGS84 的 4326）下误用平面距离公式。若你硬用 ST_Distance(geom1, geom2) ，单位是“度”，结果完全不可读；而 <code>ST_DWithin 在 SRID=4326 下默认按“米”处理（需配合 geography 类型），或明确指定投影单位。
- 必须确保至少一个参数是
geography类型，否则ST_DWithin按平面坐标解释，单位是“坐标单位”（比如度），不是米 - 常见错误：
ST_DWithin(point_geom, target_geom, 1000)—— 若两者都是geometry且 SRID=4326，1000 指的是 1000 度，约等于 11万公里 - 正确写法：
ST_DWithin(point_geom::geography, target_geom::geography, 1000)，此时 1000 单位为米
如何让 ST_DWithin 走上空间索引
没索引的 ST_DWithin 查询会全表扫描，哪怕只有 1 万条记录也可能秒变几秒响应。它能否命中 GIST 索引，取决于函数调用是否“可索引”——核心是：**不能对几何列做类型转换或函数包装**。
- ✅ 正确建索引：
CREATE INDEX idx_locations_geog ON locations USING GIST (geog)（其中geog是geography类型字段） - ✅ 查询能走索引：
SELECT * FROM locations WHERE ST_DWithin(geog, ST_GeogFromText('POINT(116.4 39.9)'), 500) - ❌ 不走索引：
SELECT * FROM locations WHERE ST_DWithin(geom::geography, ..., 500)—— 因为geom::geography是表达式，无法利用geom上的 GIST 索引 - ❌ 同样不走：
ST_DWithin(ST_Transform(geom, 3857), ..., 500)——ST_Transform是运行时计算，索引失效
距离单位和 SRID 的实际搭配规则
单位不是由函数决定的，而是由输入类型的 SRID 和类型（geometry vs geography）共同决定。搞错就搜出荒唐结果。
-
geometry+ SRID=4326 → 单位是“度”，ST_DWithin(g1, g2, 0.01)≈ 1.1 km（赤道附近），但高纬度严重失真 -
geography+ 任意 SRID（推荐显式用 4326）→ 单位是“米”，精度高，适合全球范围搜索 - 想用投影坐标系（如 Web Mercator SRID=3857）？可以，但必须用
geometry类型，且单位是“米”——只是注意：3857 在高纬度拉伸严重，1km 圆形会变成椭圆 - 别混用：
ST_DWithin(geom::geography, geog_col, 1000)可以；但ST_DWithin(geom, geog_col, 1000)会报错，类型不匹配
真实查询中容易漏掉的边界条件
上线后才发现漏了 NULL、跨日期线、或极点附近数据？这些不是语法错误，但会让结果少一半。
- NULL 几何：若
location.geog为 NULL，ST_DWithin返回 NULL，整行被过滤。加AND location.geog IS NOT NULL显式排除 - 跨国际日期变更线（如太平洋岛国）：用
geography类型自动处理，但若用geometry+ 4326 手动 wrap 经度（如把 181° 改成 -179°），反而引入误差 - 北极/南极点：WGS84 的
geography类型支持极点，但某些旧版 PostGIS（ - 性能陷阱：WHERE 条件里写成
ST_DWithin(..., $1, $2 * 1000)，虽然语义清楚，但 PostgreSQL 无法预估选择率，可能选错执行计划；建议提前算好距离值传入
PostGIS 的地理搜索不难，但错一个类型、少一个索引、或者忽略 NULL 处理，就会让结果不准或慢得没法用。最常被跳过的其实是类型一致性——宁可多写一次 ::geography，也别依赖隐式转换。
