JDBI结合PostGIS-JDBC-jtsparser传JTS几何参数时报无对应ArgumentFactory问题

该异常本质是两层适配缺失导致的：

• JDBI核心组件没有内置对org.locationtech.jts包下任意Geometry子类的参数绑定支持，无法识别这类类型该如何绑定到SQL预编译语句的占位符上。
• 你引入的postgis-jdbc 2.5.0版本jtsparser模块，仅实现了原生JDBC层面的JTS类型和PostGIS Geometry类型的互转逻辑，没有实现JDBI要求的ArgumentFactory扩展接口，不会自动被JDBI识别加载。

你当前异常日志里显示的参数值POLYGON ((-10 -10, ...))，就是因为没有匹配的参数工厂，JDBI走了兜底逻辑，把几何对象直接转成了toString后的纯文本，根本没有绑定成数据库可识别的几何类型。
你之前判断“需要在JDBI配置中注入对应ArgumentFactory”的思路是完全正确的，只是该模块本身没有提供可直接注入的现成实现类，找不到对应实现属于正常情况。

前置依赖校验 #

首先确认你引入的依赖没有版本错位：

• 核心驱动依赖使用net.postgis:postgis-jdbc:2.5.0，不要使用坐标为org.postgis:postgis-jdbc的旧版本，这类旧版本仅支持com.vividsolutions.jts包下的老JTS类型，和你代码里用到的org.locationtech.jts.geom.Polygon不兼容。
• 确认JTS核心包版本和postgis-jdbc 2.5.0匹配，不存在类路径下同时出现新旧两套JTS实现的冲突。

自定义JTS类型ArgumentFactory #

复用postgis-jdbc自带的类型转换能力，编写适配JDBI的桥接类，不需要手动实现WKB/WKT格式的序列化逻辑：

public class JtsGeometryArgumentFactory implements ArgumentFactory<Geometry> {
    @Override
    public Optional<Argument> build(Class<?> expectedType, Object value, StatementContext ctx) {
        if (value instanceof Geometry geometry) {
            return Optional.of((position, statement, context) -> {
                // 直接复用postgis-jdbc内置的转换逻辑，生成PostGIS可识别的PGgeometry类型
                PGgeometry pgGeometry = new JtsGeometryWrapper(geometry).asPGgeometry();
                statement.setObject(position, pgGeometry);
            });
        }
        return Optional.empty();
    }
}

注意：这里用到的JtsGeometryWrapper是postgis-jdbc 2.5.0版本jtsparser模块自带的类，不需要自己实现格式转换逻辑。

全局注册配置 #

把上面写好的ArgumentFactory注册到Jdbi实例的全局配置中，对所有DAO方法生效，不需要在单方法上做特殊处理：

// 在初始化Jdbi实例的代码块中添加
jdbi.registerArgument(new JtsGeometryArgumentFactory());

• 不要把JTS对象手动转成WKT字符串当String类型参数传入SQL，这种写法虽然能被PostGIS的隐式类型转换识别，但会丢失postgis-jdbc 2.5.0版本的WKB二进制传输优势，长文本场景下性能会明显下降。
• 仅注册参数绑定的ArgumentFactory是不够的，如果你的SQL查询需要返回JTS几何类型的结果，需要同步注册对应的ColumnMapper，逻辑和参数绑定类似，把数据库返回的PGgeometry类型通过JtsGeometryWrapper转成对应子类的JTS对象即可。
• 不要依赖JDBI内置的通用对象参数绑定逻辑，这类逻辑只会把对象转成toString后的字符串值，无法被PostGIS识别为合法的几何类型参数。

内容的提问来源于stack exchange，提问作者Alain B.