PostgreSQL原生不支持几何类型聚合，需启用postgis扩展后使用ST_Union()或ST_Collect()：前者拓扑融合生成单一合法几何，后者仅打包为集合类型；二者性能与用途迥异，应按需选用并注意NULL及空几何过滤。
PostgreSQL 原生不支持几何类型聚合，必须用 PostGIS 扩展
直接在纯 PostgreSQL 中对 geometry 列调用 SUM()、AVG() 或 ARRAY_AGG() 会报错：类型不匹配或函数不存在。几何对象不是标量值，无法被标准聚合函数处理。你得先确认数据库已启用 postgis 扩展：CREATE EXTENSION IF NOT EXISTS postgis;。没这一步，所有后续操作都会失败——别跳过，也别指望 pg_restore 自动带过来。
ST_Union() 是最常用的几何分组汇总函数
它把同一组内的多个几何对象合并为一个拓扑合法的单一几何（可能为 MULTIPOLYGON、POLYGON 或 GEOMETRYCOLLECTION），自动融合重叠、缝合边界、消除内部线段。适用于行政区合并、地块拼接、设施覆盖范围聚合等场景。
- 基本写法：
SELECT region, ST_Union(geom) AS merged_geom FROM parcels GROUP BY region; - 注意
ST_Union()对 NULL 输入返回 NULL，若字段含空几何（ST_IsEmpty(geom)为 true），也会参与计算并可能污染结果，建议前置过滤：WHERE geom IS NOT NULL AND NOT ST_IsEmpty(geom) - 性能敏感时，确保
geom列上有GIST索引：CREATE INDEX ON parcels USING GIST (geom);；否则GROUP BY+ST_Union可能全表扫描+内存排序 - 若分组内几何数量极大（如百万级点），
ST_Union()可能慢且吃内存；此时可改用ST_Collect()（仅打包不拓扑处理，快但非真正“融合”）
ST_Collect() vs ST_Union()：快与准的取舍
ST_Collect() 不做任何拓扑运算，只是把同组几何塞进一个 GEOMETRYCOLLECTION 或 MULTI* 类型容器里，毫秒级完成，但结果不能直接用于面积计算或空间关系判断（比如 ST_Area(ST_Collect(...)) 会报错或返回意外值）。
- 适用场景：
SELECT district, ST_Collect(geom) AS geom_collection FROM sensors GROUP BY district;—— 仅需前端渲染或传给 GIS 工具批量处理 - 关键区别：
ST_Collect()保持原始几何完整性，不合并重叠区域；ST_Union()输出是“干净”的单个几何，可安全接ST_Area()、ST_Intersects()等函数 - 别混用：
ST_Collect()返回的是集合类型，不能直接喂给依赖单一几何的函数（如ST_Centroid()会报 “function st_centroid(geometrycollection) does not exist”）
分组后还需面积/中心点？链式调用要小心顺序
常见需求是“每个区的合并图形及其面积和质心”，但不能写成 ST_Area(ST_Union(geom)), ST_Centroid(ST_Union(geom)) 两次调用——PostgreSQL 不会自动复用中间结果，会重复执行 ST_Union，开销翻倍。应改用子查询或 CTE 避免冗余计算：
WITH merged AS ( SELECT region, ST_Union(geom) AS geom FROM parcels WHERE geom IS NOT NULL AND NOT ST_IsEmpty(geom) GROUP BY region ) SELECT region, ST_Area(geom) AS total_area, ST_Centroid(geom) AS centroid FROM merged;
另外，ST_Centroid() 返回点不一定落在几何内部（比如L形多边形），业务上真需要“落点”，得用 ST_PointOnSurface() 替代。
