STRING_TO_ARRAY将字符串拆分为text[]数组，不支持正则分隔符，无法解析CSV引号规则，空输入返回含空元素数组，大字符串易OOM，类型转换需显式CAST并预处理空格。
STRING_TO_ARRAY 会把字符串拆成 text[]，不是任意类型数组
它只返回 text[]，哪怕源字符串全是数字（比如 '1,2,3'），结果也是 {'1','2','3'}，不是 integer[]。想转成其他类型得额外用 CAST 或 :: 显式转换，而且必须确保每个元素都能合法转过去，否则报错 invalid input syntax for type integer。
常见错误现象：
– 直接写 SELECT STRING_TO_ARRAY('1,2,3', ',')::integer[] → 报错
– 忘记空格干扰：'1, 2, 3' 拆出来是 {'1',' 2',' 3'}，转整数时因前导空格失败
- 先用
TRIM清理每个元素，再逐个转类型，例如：SELECT ARRAY(SELECT TRIM(x)::integer FROM UNNEST(STRING_TO_ARRAY('1, 2, 3', ',')) AS x) - 分隔符支持正则？不支持。只能是固定字符串，长度不限（可为多字符，如
'|||'），但不能是正则表达式 - 空字符串输入：
STRING_TO_ARRAY('', ',')返回{''}（含一个空元素），不是{}；要得到空数组得加条件判断
处理带引号或嵌套结构的 CSV 字符串不能只靠 STRING_TO_ARRAY
它不解析 CSV 规则：比如 '"a,b",c,"d""e"' 这种含逗号、引号、转义的字段，STRING_TO_ARRAY 会错误地在所有逗号处分割，得到 {'"a','b"', 'c', '"d""e"'} —— 完全失真。
使用场景：
– 简单无格式字符串（日志 tag 列表、权限 code 列表）可用
– 真实 CSV 数据必须用 pg_read_csv（需扩展）、COPY FROM ... WITH (FORMAT csv)，或应用层解析
- 若坚持用
STRING_TO_ARRAY处理近似 CSV，至少先替换掉引号内逗号（如用正则预处理），但 PostgreSQL 原生正则不支持“匹配不在引号内”的断言，实际很难可靠实现 - 注意
NULL表示：默认空元素就是空字符串，无法区分'a,,c'中的NULL和空字符串；要支持NULL得传第三个参数，如STRING_TO_ARRAY('a,,c', ',', '')，此时中间元素变成NULL
性能和大字符串下的边界问题
对超长字符串（比如 >10MB）调用 STRING_TO_ARRAY 可能触发内存暴涨甚至 OOM，因为整个结果数组会一次性加载进内存。PostgreSQL 不做流式拆分。
- 单次调用最大支持长度取决于
work_mem，但没硬性上限值；实测在 100MB 字符串上容易卡顿或被 cancel - 避免在 WHERE 或 JOIN 条件中对大字段反复调用，比如
WHERE 'x' = ANY(STRING_TO_ARRAY(large_column, ','))—— 先拆再查，开销远高于建 GIN 索引 +@>操作符 - 如果只是检查是否包含某值，优先考虑
large_column LIKE '%x%'（不精确但快），或提前把数组存为text[]字段并建索引
替代方案：从 JSON 字符串转数组更安全可控
如果原始数据其实是 JSON 格式（如 '["a","b","c"]' 或 '[1,2,3]'），别硬用 STRING_TO_ARRAY 拆，直接用 JSON_ARRAY_ELEMENTS_TEXT 或 JSON_ARRAY_ELEMENTS：
SELECT ARRAY_AGG(val::text) FROM JSON_ARRAY_ELEMENTS_TEXT('["a","b","c"]') AS val;
这样能天然处理引号、转义、嵌套、类型混合等问题，且 PostgreSQL 的 JSON 解析器健壮得多。
容易被忽略的一点：很多业务系统导出的“数组字符串”其实本意是 JSON，只是前端少写了方括号；与其花力气写一堆 REPLACE + TRIM 预处理，不如确认源头能否输出标准 JSON —— 这比在 SQL 层修补解析逻辑靠谱得多。
