必须显式 RETURN NEW，否则触发器中对 NEW.geom 的所有赋值均被丢弃；需先用 ST_SetSRID 补全 SRID 再调用 ST_Transform；务必创建 GIST 索引以支撑后续空间查询。
触发器函数里不能直接用 ST_Transform 处理未知 SRID 的几何字段
PostgreSQL 触发器中对 GEOMETRY 字段做坐标系转换时，如果源数据 SRID 为空或不一致，ST_Transform 会直接报错 ERROR: transform: no input geometry 或 ERROR: Operation on two geometries with different SRIDs。这不是语法问题，而是空间元数据缺失导致的运行时失败。
实操建议：
- 在触发器函数开头强制校验并补全 SRID：用
ST_SetSRID+ST_SRID判断，例如IF ST_SRID(NEW.geom) = 0 THEN NEW.geom := ST_SetSRID(NEW.geom, 4326); END IF; - 转换前统一目标 SRID：避免硬编码，把目标 SRID（如
3857）作为函数参数或配置表读取，方便后期调整 - 用
ST_Envelope或ST_Centroid做轻量级计算时，也需确保输入几何已带 SRID，否则结果不可靠
UPDATE 触发器中修改 NEW.geom 后必须 RETURN NEW
PostgreSQL 的 BEFORE UPDATE 触发器函数若想让几何字段更新生效，必须显式 RETURN NEW。漏掉这句，所有对 NEW.geom 的赋值操作都会被丢弃，表数据保持原样——而错误日志里不会报任何异常，极易误判为逻辑未执行。
常见陷阱：
- 在条件分支里只对部分情况
RETURN NEW，其他路径没写，导致某些更新静默失效 - 调用
RAISE NOTICE后忘记RETURN NEW，以为日志输出就等于执行成功 - 误用
RETURN NULL（会跳过本次更新），或RETURN OLD（相当于取消更新）
触发器性能瓶颈常来自 ST_Buffer 或 ST_Union 等耗时空间函数
在高频更新的表上，触发器里调用 ST_Buffer、ST_Union、ST_Intersects（尤其无空间索引时）会导致单次 UPDATE 延迟飙升，甚至阻塞并发写入。这不是 PostgreSQL 本身限制，而是几何运算 CPU 密集型的本质决定的。
优化方向：
- 优先用
ST_Within替代ST_Intersects做点面关系判断，前者可走GIST索引且计算更快 -
ST_Buffer半径设为 0 时仍会生成新几何，若仅需拓扑一致性检查，改用ST_IsValid+ST_MakeValid更轻量 - 批量更新时（如
UPDATE ... SET geom = ST_Transform(geom, 3857)），禁用触发器比逐行触发更高效：SET session_replication_role = 'replica';临时绕过
触发器无法自动维护空间索引，需手动确保 GIST 索引存在
即使触发器成功更新了几何字段，如果表上没有 USING GIST (geom) 索引，后续的 WHERE ST_DWithin(geom, ...) 查询仍会全表扫描。触发器本身不感知索引，也不会报错提醒你缺索引。
检查与补救：
- 确认索引存在：
SELECT indexname FROM pg_indexes WHERE tablename = 'your_table' AND indexdef LIKE '%USING GIST%'; - 创建缺失索引：
CREATE INDEX CONCURRENTLY ON your_table USING GIST (geom);（加CONCURRENTLY避免锁表） - 更新后验证索引是否被使用：用
EXPLAIN ANALYZE查看查询计划中是否出现Index Scan using ...
触发器处理地理空间数据最麻烦的不是写法，而是 SRID 隐式丢失、索引缺失和返回值遗漏这三类“静默故障”——它们不会让 SQL 报错，但会让空间查询结果错得毫无征兆。
