ST_Contains是最稳妥的点位归属判断函数，要求多边形严格包含点，避免浮点误差漏判；须确保边界表有空间索引、点转为带SRID的POINT、JOIN中使用ST_Contains而非WHERE，以保障性能与准确性。
用 ST_Contains + 多边形边界表做点位归属判断
直接用经纬度字段做 GROUP BY 无法体现地理邻近性，必须先将每个点落到实际行政或自定义区域（如省/市/网格单元）内。核心是用空间函数判断点是否在某个多边形内，ST_Contains 是最稳妥的选择——它明确要求「多边形包含点」，不会因边界浮点误差漏判。
常见错误是误用 ST_Intersects：它对点和面的交集判定等价于 ST_Contains，但一旦后续换成线状区域（如道路缓冲区），逻辑就失效；还有人用 ST_DWithin 配合点查圆，这本质是距离聚合，不是边界聚合，会跨行政区划“拉平”真实地理约束。
- 确保边界表（如
regions）有合法的POLYGON或MULTIPOLYGON几何列，且已建立空间索引：CREATE INDEX idx_regions_geom ON regions USING GIST (geom); - 原始点表（如
locations）的经纬度需转为POINT类型，注意 SRID 一致性（国内常用EPSG:4326）：ST_SetSRID(ST_MakePoint(lon, lat), 4326) - JOIN 时务必加
ON ST_Contains(r.geom, l.point_geom)，别写成WHERE ST_Contains(...)，否则无法利用空间索引，查询可能从秒级变分钟级
用 ST_SnapToGrid 实现规则矩形网格聚合
当不需要严格按行政边界，而要统计「每 0.01 度×0.01 度网格内有多少点」这类规则划分时，ST_SnapToGrid 比手写 FLOOR(lon/0.01)*0.01 更可靠——它自动处理负经度、跨本初子午线等边界情况，且返回仍是几何类型，可直接参与空间运算。
注意：网格精度单位是「度」，不是米。在赤道附近 0.01° ≈ 1.1 km，到北纬50°就缩至 ≈ 0.7 km。若需等距网格（如 1km×1km），必须先用 ST_Transform 转到投影坐标系（如 EPSG:3857 或地方坐标系），再 ST_SnapToGrid，否则网格会严重畸变。
- 简单经纬度网格示例：
ST_SnapToGrid(ST_SetSRID(ST_MakePoint(lon, lat), 4326), 0.01, 0.01) - 等距网格必须两步：先
ST_Transform(geom, 3857)，再ST_SnapToGrid(..., 1000, 1000)（单位是米） -
ST_SnapToGrid返回的是点，聚合时需用ST_AsText或哈希值做分组键，避免浮点精度导致同一网格被拆成多组
PostGIS 中避免 ST_Centroid 导致的跨区偏移
有人想“先按区域聚合，再取中心点”，于是写 ST_Centroid(ST_Union(geom))。这很危险：行政区域可能是不规则多部件（如海岛+主陆）、带孔洞（湖泊），ST_Centroid 返回的质心可能落在水域或区域外，导致后续空间关联失败。
真正需要代表位置时，优先用 ST_PointOnSurface——它保证返回的点一定在多边形内部，且算法稳定；若必须用几何中心，至少加兜底：COALESCE(ST_PointOnSurface(r.geom), ST_Centroid(r.geom))。
- 聚合后想展示每个区域一个标记点？用
ST_PointOnSurface，不是ST_Centroid - 用
ST_Centroid做空间 JOIN 键？大概率出错，尤其在省级以上大区域或海洋省份 - 边界数据本身质量差（如自相交、环方向错）会导致
ST_PointOnSurface失败，上线前务必用ST_IsValid和ST_MakeValid扫描清洗
性能瓶颈往往卡在空间索引未生效或数据未分区
千万级点表 + 全国区划表一查就超时，90% 是因为没让空间索引真正参与。典型表现：EXPLAIN 显示 Seq Scan on 区域表，或 Index Scan 但 rows=0。
- 确认空间列类型是
geometry（不是geography），且索引类型是GIST（SPATIAL索引名是 MySQL 的，PostGIS 只认GIST） - 点表量大时，给点表也建空间索引：
CREATE INDEX idx_locations_geom ON locations USING GIST (point_geom);，能加速反向查询（如“某区域周边5km有哪些点”） - 全国数据按省分表（
regions_shandong,regions_guangdong）比单表快得多，PostgreSQL 分区表（PARTITION BY LIST）也可行，但需业务层路由
网格聚合的真实复杂点不在 SQL 写法，而在坐标系选择、边界数据拓扑质量、以及索引是否被 planner 采纳——这三者任一出问题，结果可能全对但慢得没法用，或者快得飞起但部分点永远找不到归属。
