ARRAY是显式构造符，主动推断类型；{}是字面量，依赖上下文，无法表达空数组，多维需逐层ARRAY构造，类型标注防推断偏差，索引与约束需注意使用方式。
PostgreSQL插入数组数据时，ARRAY和{}语法的区别在哪
两者都能插入数组，但语义和类型推断逻辑不同：ARRAY是显式构造符，会主动推断元素类型；{}是字面量语法，依赖上下文或列定义来确定类型。如果目标列类型未明确（比如text[] vs varchar[]），{}可能报错cannot determine type of empty array或类型不匹配。
实操建议：
- 列已定义为具体数组类型（如
tags text[]）时，INSERT INTO t VALUES ('{a,b,c}')通常能成功 - 插入
NULL元素或空数组时，必须用ARRAY[NULL]或ARRAY[]::text[]，{}无法表达空数组类型 - 跨类型混合（如
{1,'abc'}）在{}中直接报错，而ARRAY[1, 'abc']会尝试转成text[]（因字符串字面量优先级更高）
用ARRAY构造多维数组的正确写法
PostgreSQL不支持ARRAY[[1,2],[3,4]]这种嵌套写法——它会被解析为一维text[]（因为内部逗号被当成分隔符）。必须用ARRAY逐层构造，并显式声明维度类型。
实操建议：
- 二维整数数组：用
ARRAY[ARRAY[1,2], ARRAY[3,4]]::int[][] - 省略类型标注时，若元素全为数字，可能被推断为
numeric[]而非int[]，影响索引或约束行为 -
ARRAY内嵌SELECT子查询（如ARRAY(SELECT id FROM users LIMIT 3)）只支持一维，且子查询必须返回单列
从JSON或字符串动态生成数组时的常见坑
用string_to_array()或json_array_elements_text()转换时，容易忽略空字符串、多余空格、NULL处理。
实操建议：
-
string_to_array('a, b ,c', ',')结果是{'a',' b ','c'}——前后空格保留，需配合trim()：ARRAY(SELECT trim(x) FROM unnest(string_to_array('a, b ,c', ',')) AS x) - JSON数组
["a",null,"b"]经json_array_elements_text()后null变成字符串'null'，要用json_array_elements()再强制转类型 - 直接拼接
{}字符串（如'{' || arr_str || '}'）属于SQL注入高危操作，必须用ARRAY构造或to_jsonb()+jsonb_array_elements_text()
插入数组时索引和约束失效的隐性原因
数组列上建GIN索引后，查询WHERE tags @> ARRAY['x']能走索引，但WHERE tags && ARRAY['x']（重叠）或WHERE tags[1] = 'x'（下标访问）可能不走索引，尤其当数组长度变异大时。
实操建议：
- 对高频查询的下标位置（如
status_code int[]总查第一个值），考虑拆出单独列并建B-tree索引 - 使用
array_length(tags, 1) > 0判断非空比tags != '{}'更可靠，后者在某些版本中无法利用索引 - 外键约束不能直接作用于数组元素——要确保元素值存在，得靠触发器或应用层校验
数组类型看着简单，但类型推断、维度控制、NULL语义和索引行为这四块最容易在上线后暴露问题。尤其是从其他数据库迁移或前端传参解析时，别图省事用字符串拼{}，老实用ARRAY加类型标注。
