这确实是H2GIS和PostGIS之间挺常见的兼容性坑，我给你整理几个可行的解决方向，你可以根据自己的测试需求选：

1. 在H2中自定义<->运算符 #

H2数据库支持自定义运算符，我们可以把PostGIS的<->运算符映射到H2GIS提供的ST_Distance函数上，这样就能在语法层面兼容了。

你可以在测试启动阶段（比如用Spring Boot的@Sql注解或者初始化脚本）执行以下SQL：

CREATE OPERATOR <-> (
  LEFTARG = GEOMETRY,
  RIGHTARG = GEOMETRY,
  FUNCTION = ST_DISTANCE,
  RETURN TYPE = DOUBLE
);

不过要注意两个点：

• H2的自定义运算符语法和PostgreSQL略有差异，得确保H2GIS版本支持这种配置
• PostGIS的<->运算符自带KNN查询的索引优化，但H2大概率没有对应的优化逻辑，如果你的查询依赖这个优化来提升性能，测试时可能会有性能下降，但语法错误问题能解决

2. 针对测试环境替换查询语句 #

如果自定义运算符的方式有兼容性问题，你可以用Spring Boot的环境配置能力，给生产和测试环境准备两套查询逻辑：

• 生产环境保留原有的<->运算符查询，比如：SELECT * FROM locations WHERE geom <-> ? ORDER BY geom <-> ? LIMIT 5
• 测试环境把<->替换为ST_DISTANCE函数，比如：SELECT * FROM locations ORDER BY ST_DISTANCE(geom, ?) LIMIT 5

你可以通过@Profile注解或者不同环境的配置文件（比如application-test.yml）来切换查询语句，缺点是需要维护两套查询逻辑，但如果你的空间查询数量不多，这种方式成本很低。

3. 用Testcontainers+PostGIS容器做测试 #

如果你的测试需要完全兼容PostGIS的所有特性（包括<->的KNN优化、复杂空间函数等），最靠谱的方案还是用Docker容器跑真实的PostGIS数据库，再结合Testcontainers来自动管理容器生命周期。

Spring Boot和Testcontainers集成非常方便：

• 添加Testcontainers的PostGIS依赖到你的测试依赖中
• 在测试类中用@Container注解启动PostGIS容器，自动配置数据源指向这个容器
• 测试启动时会自动拉取PostGIS镜像、创建容器，测试结束后自动销毁，完全不用手动维护容器

这种方案能保证测试环境和生产环境的数据库行为完全一致，不会出现兼容性问题，适合复杂的空间查询场景。

内容的提问来源于stack exchange，提问作者JoschJava