ST_Transform转换前须确保几何列有明确SRID，否则报错；ST_DWithin距离单位取决于输入几何的SRID，WGS84下为度而非米，应先投影或改用ST_DistanceSphere。
ST_Transform 转换坐标系前必须确认源SRID
视图里用 ST_Transform 做投影转换，如果原始几何列没显式声明 SRID，PostGIS 会默认当成 0（未知），这时 ST_Transform(geom, 4326) 会报错：ERROR: transform: couldn't project point。不是函数写错了，是数据本身缺元信息。
实操建议：
- 建表时务必用
geometry(Point, 4326)这类带 SRID 的类型定义，而不是裸geometry - 若已有数据没设 SRID，先用
ST_SetSRID(geom, 4326)补上，再传给ST_Transform；顺序不能反 - 在视图中嵌套写法要小心：
ST_Transform(ST_SetSRID(geom, 4326), 3857)是安全的，但ST_Transform(geom, 3857)直接报错
ST_DWithin 判断邻近关系时单位依赖 SRID
ST_DWithin 在视图里常用来做“某点 500 米内有哪些设施”，但它的第三个参数（距离）单位不是固定“米”——它和输入几何的 SRID 单位一致。如果 geom 是 WGS84（SRID=4326），那 ST_DWithin(geom, ref_geom, 0.005) 的 0.005 是度（≈550 米），不是米；直接写 500 就完全失效。
实操建议：
- 统一先转到投影坐标系（如
3857或本地 UTM），再用ST_DWithin，此时距离单位才是米 - 或改用
ST_DistanceSphere+ 比较（ST_DistanceSphere(a.geom, b.geom) ），它内部按球面算，单位恒为米，但性能略低 - 别在视图里混用不同 SRID 的几何列参与
ST_DWithin，隐式转换不可控
ST_Union 聚合地理边界时需先 ST_MakeValid
从 OpenStreetMap 或 Shapefile 导入的数据常含自相交、环方向错误等拓扑问题，直接在视图里对 geom 做 ST_Union 可能返回 NULL 或空结果，且不报错——这是 PostGIS 的静默失败行为。
实操建议：
- 聚合前加
ST_MakeValid：ST_Union(ST_MakeValid(geom))，它会尝试修复并返回最接近的合法几何 - 若修复后仍含
GeometryCollection，而下游只接受Polygon，需再套(ST_Dump(ST_Union(...))).geom提取单一部分 - 注意
ST_Union在视图中是逐行计算，大数据量时建议先在物化视图或临时表里预聚合，避免每次查询都重算
视图中用 ST_AsText 或 ST_AsGeoJSON 会丢失二进制精度
有些业务需要把地理数据转成文本格式供前端解析，但在视图里直接用 ST_AsText(geom) 或 ST_AsGeoJSON(geom) 输出，会导致小数位截断（默认 15 位），尤其高精度测绘数据可能产生几厘米偏差；而且文本字段无法被空间索引加速。
实操建议：
- 视图里保留原始
geometry列，仅在 SELECT 末尾按需调用ST_AsGeoJSON，不要把它作为视图主字段长期存储 - 若必须输出 GeoJSON，用
ST_AsGeoJSON(geom, 8)显式控制小数位（8 位 ≈ 1cm 精度），避免默认行为 - 前端真正需要的是坐标数组？那就用
ST_AsEWKB+ 客户端解析，或者直接走ST_X/ST_Y拆点，比文本更稳
地理空间视图最麻烦的不是函数不会用，而是每个 ST_* 函数背后都绑着坐标系、拓扑规则、精度策略三层隐含约束。漏掉其中一层，查询看似跑通，结果却在地图上偏移几百米——这种问题很难一眼发现。
