thinkphp默认不支持postgis空间函数，因其pgsql驱动未启用postgis扩展、不识别geometry/geography类型，且orm未注册空间函数白名单；即使polardb已预装postgis，仍需手动配置pdo选项、使用原生sql调用st_*函数，并严格统一srid（如4326）以避免静默计算错误。
ThinkPHP 无法直接用原生 PostgreSQL 的 PostGIS 函数做空间查询，必须显式启用扩展并绕过 ORM 的字段类型限制。
为什么默认配置连不上 PolarDB PostgreSQL 的 PostGIS 功能
ThinkPHP 的 pgsql 驱动只做基础连接和简单 SQL 转义，不加载 postgis 扩展，也不识别 geometry、geography 这类空间类型。即使 PolarDB PostgreSQL 实例已执行 CREATE EXTENSION postgis;，TP 仍会把含 ST_DWithin、ST_Intersects 的查询当普通字符串处理，导致语法错误或空结果。
- 常见报错：
ERROR: function st_dwithin(unknown, unknown, double precision) does not exist - 根本原因：PHP 的
pgsql扩展未启用postgis类型映射，且 TP 的Query类未注册空间函数白名单 - 不是数据库权限问题，也不是阿里云控制台没开扩展——PolarDB PG 版默认已预装
postgis，但应用层需主动触发
ThinkPHP 6/7 中正确启用 PostGIS 查询的三步操作
绕过 ORM 对字段类型的硬编码判断，用原生查询 + 手动绑定方式调用空间函数：
- 在数据库配置中显式添加
'options' => [PDO::ATTR_EMULATE_PREPARES => false]，避免预处理时丢失geometry字段元信息 - 查询时不用
where()链式调用，改用query()->execute()或Db::raw()包裹完整 SQL，例如：Db::raw("ST_DWithin(location, ST_Point(120.1,30.2), 5000)") - 对
geometry字段插入数据时，必须用ST_GeomFromText('POINT(120.1 30.2)', 4326)显式构造，不能传 PHP 数组或 JSON 字符串
GeoJSON 输入输出要自己转换，TP 不提供自动序列化
ThinkPHP 默认不解析 geometry 字段返回的二进制 WKB 或 text 格式，直接 select 会得到乱码或空值。
- 读取时用
ST_AsGeoJSON(location)转成标准 GeoJSON 字符串，再用json_decode()处理 - 写入时先用
json_encode()把 GeoJSON 对象转回字符串，再套ST_GeomFromGeoJSON() - 别依赖
toJson()或toArray()自动包含空间字段——它们会跳过geometry列，除非你重写模型的getAttr()方法
阿里云 PolarDB PG 版的 SRID 必须显式指定，否则空间计算失效
PolarDB PostgreSQL 版底层使用的是标准 PostGIS，但它的默认 SRID（坐标系）不是 4326，尤其在新建库或导入数据后容易被忽略。
- 建表时必须声明：
location geometry(Point, 4326)，不能只写geometry(Point) - 所有
ST_*函数调用都带 SRID 参数，例如ST_Transform(ST_SetSRID(ST_MakePoint(lon, lat), 4326), 3857) - 用
SELECT Find_SRID('public', 'your_table', 'location');确认实际 SRID，阿里云控制台的“空间索引”开关不影响该值
最易被忽略的是 SRID 一致性——哪怕只漏掉一个 ST_SetSRID()，整个距离计算就变成平面直角坐标系下的错误结果，而错误本身不会报错，只会返回空或偏差极大的数据。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
