PostgreSQL函数定义数组参数应使用integer[]、text[]等标准语法，禁用int[]等缩写；传参推荐ARRAY[1,2,3]字面量或JDBC createArrayOf()，避免MyBatis/JPA原生查询直接传List导致类型不匹配。
PostgreSQL函数定义时如何声明数组参数
直接在函数参数列表里用 _int4、text[] 或 bigint[] 即可，PostgreSQL原生支持。注意写法差异：
-
_int4是老式写法（对应integer[]），语义清晰但易被误读为“下划线加int4” -
integer[]更推荐，类型意图明确，和 SQL 字面量ARRAY[1,2,3]一致 - 自定义复合类型数组如
mytype[]，需确保该类型已CREATE TYPE且权限正确
错误示例：int[] 不合法——PostgreSQL 不识别缩写 int，必须用 integer、bigint 等完整类型名。
调用时传数组的三种常见方式及坑点
不是所有传法都等价，JDBC/MyBatis/Spring Data JPA 在底层处理逻辑不同，容易因格式错配报 function xxx does not exist：
- SQL 字面量：直接写
ARRAY[1,2,3]或'{1,2,3}'::integer[]——安全，但无法参数化，有 SQL 注入风险 - JDBC
Connection.createArrayOf()：需显式指定 JDBC 类型（如Types.INTEGER），且驱动版本 ≥ 42.2 才稳定支持数组绑定 - 字符串拼接 +
string_to_array()：例如传"1,2,3"，函数内写string_to_array($1, ',')::integer[]——兼容性最强，但要注意空字符串、空白、单元素边界情况
特别注意：MyBatis 默认不识别 Java List 到 PostgreSQL 数组的自动转换，必须配 TypeHandler 或改用 #{xxx, typeHandler=ArrayTypeHandler}。
在函数体内用 UNNEST 还是直接下标遍历
UNNEST 是最自然的展开方式，尤其配合 JOIN 或集合操作；而手动 FOR i IN array_lower(arr,1)..array_upper(arr,1) 易出界、难维护：
- 用
UNNEST可直接参与WHERE IN类逻辑：UPDATE t SET x = 'done' WHERE id IN (SELECT * FROM UNNEST($1)) - 若需带序号或去重，加
WITH ORDINALITY：SELECT val, ord FROM UNNEST($1) WITH ORDINALITY AS t(val, ord) - 避免对空数组调用
UNNEST导致结果集为空——如果业务逻辑依赖“至少一行”，需提前IF array_length($1, 1) IS NULL THEN ... END IF;
别在循环里反复调用 array_length()，它不是 O(1)，对大数组有开销；取一次存变量更稳妥。
Spring Boot + JPA 原生查询传 List 失败的根本原因
不是 Spring 的 bug，而是 JDBC 规范限制：原生 @Query(nativeQuery = true) 绑定参数时，List 被当作多个独立参数展开，而非一个数组对象。所以 :ids 实际被替换成 1, 2, 3，导致 PostgreSQL 解析成三个 bigint 参数，而非一个 bigint[]。
- 绕过方式：把
List转成字符串，在 SQL 中用string_to_array(:idsStr, ',')::bigint[] - 更健壮的做法：改用
JdbcTemplate+createArrayOf()，绕过 JPA 的参数解析层 - 切记：
string_to_array返回text[]，必须显式强转，比如string_to_array(:idsStr, ',')::bigint[]，否则类型不匹配
数组长度超 1000 元素时，string_to_array 方案可能触发 SQL 长度限制，此时必须切回 createArrayOf 或分批调用。
