PostGIS 团队发布了 3.7.0beta1。这个版本继续修复 3.7.0alpha1 之后的问题，并为 3.7 大版本补充增强。它适合兼容性验证、扩展开发和空间查询回归测试，但 Beta 标签也意味着它不应直接替换生产环境中的稳定版本。
运行环境的硬门槛
根据发布摘要，PostGIS 3.7.0beta1 的基础依赖如下：
| 组件 | 最低或兼容版本 | 说明 |
|---|---|---|
| PostgreSQL | 14 至 19beta2 | PostgreSQL 19 仍属于测试版本组合 |
| GEOS | 3.10+ | 使用全部相关特性需要 GEOS 3.15+ |
| PROJ | 6.1+ | 坐标参考系统与投影转换依赖 |
| SFCGAL | 2.3.0+ | 使用全部 SFCGAL 特性时需要 |
发布说明特别推荐将其与 PostgreSQL 19 Beta 2、GEOS 3.15.0beta2 一起测试。这是一套偏向前沿验证的组合，不等于生产部署建议。若团队只想评估 PostGIS 3.7，可以优先使用现有支持范围内的稳定 PostgreSQL，并单独控制 GEOS、PROJ 与 SFCGAL 的版本变量。
这里还有一个值得留意的文本问题：摘要开头明确称该版本为 beta1，末尾却写成“alpha of a major release”，并提到自 PostGIS 3.7.4 以来的修复。后两处与版本时间线并不一致，更像是发布文案残留。评估版本性质时，应以 3.7.0beta1 标识以及对应的 NEWS、构建文件和实际测试结果为准。
不要只检查扩展版本
PostGIS 运行在 PostgreSQL 内部，但空间运算还会经过 GEOS、PROJ，某些功能也会调用 SFCGAL。数据库成功执行 CREATE EXTENSION，只能证明扩展基本可加载，不能证明动态链接库版本符合预期。
可以在测试实例中执行下面的 SQL，集中记录数据库、PostGIS 及底层依赖信息：
CREATE EXTENSION IF NOT EXISTS postgis;
SELECT version() AS postgresql_version;
SELECT postgis_full_version() AS postgis_build;
SELECT postgis_geos_version() AS geos_version;
SELECT postgis_proj_version() AS proj_version;
SELECT extname, extversion
FROM pg_extension
WHERE extname LIKE 'postgis%'
ORDER BY extname;
使用 psql 时，可以直接运行：
psql "$DATABASE_URL" -v ON_ERROR_STOP=1 <<'SQL'
CREATE EXTENSION IF NOT EXISTS postgis;
SELECT version();
SELECT postgis_full_version();
SELECT postgis_geos_version();
SELECT postgis_proj_version();
SQL
运行前把 DATABASE_URL 设置为测试数据库连接串，例如：
export DATABASE_URL='postgresql://postgres:postgres@127.0.0.1:5432/gis_test'
postgis_full_version() 的输出应保存到 CI 构建产物中。这样遇到几何结果差异时，可以判断变化来自 PostGIS 本身，还是来自 GEOS、PROJ 等底层库。
建立一个最小空间回归样例
发布摘要没有列出具体新增函数，因此不宜凭空把某个 API 归为 3.7 新特性。实际评估时，可以这样实践：用团队常见的坐标转换、空间关系和缓冲区查询建立一组最小冒烟测试。
下面的脚本可以直接在启用了 PostGIS 的测试数据库中运行：
BEGIN;
CREATE TEMP TABLE places (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name text NOT NULL,
geom geometry(Point, 4326) NOT NULL
);
INSERT INTO places (name, geom) VALUES
('Shanghai', ST_SetSRID(ST_MakePoint(121.4737, 31.2304), 4326)),
('Hangzhou', ST_SetSRID(ST_MakePoint(120.1551, 30.2741), 4326));
-- 在适合距离计算的投影坐标系中计算两点距离。
SELECT round(
ST_Distance(
(SELECT ST_Transform(geom, 3857) FROM places WHERE name = 'Shanghai'),
(SELECT ST_Transform(geom, 3857) FROM places WHERE name = 'Hangzhou')
)::numeric,
2
) AS distance_meters;
-- 验证缓冲区、相交判断与几何有效性。
WITH area AS (
SELECT ST_Buffer(ST_Transform(geom, 3857), 5000) AS geom
FROM places
WHERE name = 'Shanghai'
)
SELECT
ST_IsValid(area.geom) AS buffer_is_valid,
count(*) FILTER (
WHERE ST_Intersects(ST_Transform(places.geom, 3857), area.geom)
) AS points_in_buffer
FROM area
CROSS JOIN places
GROUP BY area.geom;
ROLLBACK;
示例中的 Web Mercator 只用于构造简短、可重复的测试。生产系统进行精确测距或面积计算时，应选择适合业务区域的投影坐标系，或者使用 geography 类型，并为误差范围设置明确断言。
真正的回归测试还应覆盖业务数据中的无效多边形、空几何、三维坐标、跨日期变更的数据以及靠近坐标系边界的对象。GEOS 升级可能影响叠加、缓冲和有效性修复等运算的细节结果，因此不要只比较查询是否成功，还要比较几何类型、SRID、有效性、对象数量和允许误差内的面积或距离。
如何安排 Beta 验证
建议把 3.7.0beta1 放进独立实例，不要在唯一的生产副本上原地升级。测试流程至少应包含以下检查：
- 记录 PostgreSQL、PostGIS、GEOS、PROJ 和 SFCGAL 的精确版本。
- 从脱敏备份恢复一份有代表性的空间数据。
- 重放高频查询，并比较结果、执行时间和查询计划。
- 检查 GiST、SP-GiST 或 BRIN 空间索引是否仍被预期查询使用。
- 对坐标转换、几何修复、叠加分析和栅格处理分别做回归测试。
- 保留旧环境以及可执行的回退步骤，不要把扩展降级当作默认恢复方案。
如果团队依赖 GEOS 3.15 或 SFCGAL 2.3 才能获得的完整能力，应把这些库也视为测试中的独立升级项。一次同时更换 PostgreSQL、PostGIS、GEOS、PROJ 和 SFCGAL，会扩大问题定位范围；分层建立基线，才能知道行为变化究竟来自哪一层。
采用建议
PostGIS 3.7.0beta1 的主要价值，是提前暴露 PostgreSQL 14 至 19beta2、GEOS 3.10+ 和 PROJ 6.1+ 组合中的兼容性问题。扩展作者、发行版维护者以及空间计算较重的团队可以现在开始验证；普通生产系统则应等待稳定版本，并确认所用操作系统或容器镜像提供了经过测试的依赖组合。
升级决策不要只看 postgis 扩展号。把数据库版本、动态库版本、真实空间数据和业务查询放在同一份测试报告中，才足以判断 3.7 是否已经适合进入生产变更窗口。