st_dwithin配合group by可实现以点为中心的邻域距离分组，需先转投影坐标系、建gist索引，并避免全表自连接。
用 ST_DWithin 配合 GROUP BY 实现距离分组
PostgreSQL 本身不支持“按某半径内最近点自动聚类”，但可以通过 ST_DWithin 判断两点是否在指定距离内，再结合自连接或窗口函数模拟分组逻辑。最常用且可控的方式是：先定义一个参考点集（比如每个点作为中心），再找出所有落在其 radius 内的点，最后按该中心点聚合——本质是“以点为中心的邻域聚合”。
常见错误是直接写 GROUP BY ST_Transform(geom, 3857) 或试图用 ST_ClusterDBSCAN 后再聚合，前者无法表达距离语义，后者返回的是簇 ID 而非地理连续范围，且不保证边界对齐业务需求。
- 必须确保坐标系单位与
ST_DWithin的distance参数匹配：地理坐标（EPSG:4326）下单位是度，建议先转为投影坐标系（如EPSG:3857，单位米） -
ST_DWithin在索引列上才高效，务必为geom字段建立GIST索引：CREATE INDEX idx_locations_geom ON locations USING GIST (geom); - 若数据量大，避免全表自连接；可加
WHERE a.id 去重，或改用 <code>LATERAL子查询限制右侧扫描范围
用 LATERAL + ST_DWithin 避免笛卡尔积爆炸
自连接容易导致 N² 复杂度，尤其当单个中心点周围有大量邻近点时。用 LATERAL 可让右侧子查询“按需执行”，每次只查当前左侧行的邻域，性能更可控。
SELECT
a.id AS center_id,
COUNT(b.id) AS nearby_count,
AVG(b.temperature) AS avg_temp
FROM locations a
LEFT JOIN LATERAL (
SELECT id, temperature
FROM locations b
WHERE ST_DWithin(a.geom, b.geom, 1000) -- 单位：米（需 a.geom 已转 EPSG:3857）
AND b.id != a.id
) b ON true
GROUP BY a.id;
注意：这里 ST_DWithin 的第三个参数是米，前提是 a.geom 和 b.geom 都是 Web Mercator（EPSG:3857）。如果原始是 EPSG:4326，得先用 ST_Transform 转换，否则 1000 表示 1000 度，毫无意义。
- 不要在
LATERAL子查询里漏掉AND b.id != a.id，否则中心点自己也会被计入邻域 - 若只需“每个点所属的最近簇”，而非“每个点统计其邻域”，应考虑
ST_ClusterDBSCAN，但它不接受固定半径作为输入，而是基于密度自适应生成簇 -
LATERAL在 PostgreSQL 9.3+ 支持，旧版本只能退回到带条件的自连接
用 ST_ClusterDBSCAN 做无监督空间聚类（非固定距离分组）
如果你的真实需求是“把彼此靠近的点自动划成一组”，而不是“每个点都算自己为中心拉一个圆”，那 ST_ClusterDBSCAN 更合适。它基于密度，能识别噪声点、处理不规则形状簇，但它的 eps 参数虽是距离阈值，实际分组结果并不等价于“所有两两距离 ≤ eps”的完全连通图。
SELECT
cluster_id,
COUNT(*) AS size,
ST_Centroid(ST_Collect(geom)) AS centroid
FROM (
SELECT
geom,
ST_ClusterDBSCAN(geom, eps := 1000, minpoints := 3) OVER() AS cluster_id
FROM locations_3857
) t
WHERE cluster_id IS NOT NULL
GROUP BY cluster_id;
关键差异在于：ST_ClusterDBSCAN 要求所有输入几何在同一投影坐标系下，且 eps 单位必须与坐标系单位一致（如米）。它不会为每个点单独生成一个邻域，而是全局分析连通性，因此不能替代“以每个点为圆心的独立距离聚合”。
-
minpoints设置过小（如 1）会导致每个点都成一簇；过大则可能全归为噪声（NULLcluster_id） - 结果中
cluster_id = NULL的点被视为离群值，需显式过滤才能进聚合 - 该函数不支持在索引上加速，大数据量时比
ST_DWithin慢得多
距离单位与坐标系错配是最常踩的坑
几乎所有“距离计算结果明显不对”的问题，根源都在单位混淆。PostgreSQL 的空间函数对坐标系极其敏感：
- 原始数据是
EPSG:4326（经纬度），直接传ST_DWithin(geom, ref_geom, 1000)—— 这里的 1000 是度，相当于赤道上约 111 公里，高纬度地区横向距离急剧缩小 - 用
ST_Transform(geom, 3857)转了坐标，但没确认目标 SRID 是否真支持距离测量（3857在高纬度会严重拉伸，仅适合可视化，不适合精确距离） - 正确做法：对中纬度区域，优先用
UTM分区（如EPSG:32633），它在局部范围内单位米且变形小；或使用ST_DistanceSphere/ST_DistanceSpheroid做球面距离计算，但它们不能利用空间索引，仅适合小数据量校验
真正要上线的距离聚合逻辑，几乎都得先做一次 ST_Transform 投影转换，并确保整个流程（索引、查询、聚合）都基于同一投影坐标系。这步漏掉，后面所有优化都是徒劳。
