split_part返回空字符串而非报错，因它对非法位置（≤0或越界）及空字段均静默处理；索引从1开始，分隔符为普通字符串，不支持正则，null输入导致结果为null。
为什么 SPLIT_PART 返回空或报错？
SPLIT_PART 是 PostgreSQL 提供的字符串切分函数，但它不支持正则、不处理空字段、且索引从 1 开始——这是最常踩坑的地方。如果你传入了 0 或负数作为位置参数，它不会报错，而是静默返回空字符串；如果指定位置超出实际分割后数组长度，同样返回空，而不是 NULL 或抛异常。
常见错误现象：SPLIT_PART('a,b,c', ',', 0) 得到空字符串；SPLIT_PART('a,,c', ',', 2) 也返回空（因为中间是两个连续逗号，产生空元素，第 2 个确实是空）。
- 位置参数必须是正整数，最小为
1 - 分隔符是普通字符串，不是正则；想用正则请改用
REGEXP_SPLIT_TO_ARRAY - 输入字符串为
NULL时，整个结果为NULL，不是空字符串
SPLIT_PART 的正确调用方式与参数含义
语法是 SPLIT_PART(string, delimiter, field_number)，三个参数都必须提供，且类型固定：string 和 delimiter 是 text，field_number 是 integer。
示例：从路径中提取数据库名
SELECT SPLIT_PART('/var/lib/postgresql/15/main', '/', 5); -- 返回 'postgresql'
注意：'/var/lib/postgresql/15/main' 按 '/' 切分后是 {'', 'var', 'lib', 'postgresql', '15', 'main'}，首项为空（因路径以 / 开头），所以第 5 个是 '15'，不是 'postgresql'——这里容易数错。
- 分隔符长度不限，可以是
'::'、' | '等任意字符串 - 如果分隔符在字符串中未出现，整个原字符串被视为第 1 个部分，其余位置均返回空
- 性能上无明显开销，但频繁嵌套使用（如多层
SPLIT_PART套用）可能影响可读性和维护性
如何安全提取第 N 个值并避免越界？
PostgreSQL 没有内置“安全取第 N 个”的变体，得自己兜底。常用做法是先用 ARRAY_LENGTH 检查分割后数组长度，再结合 CASE 返回默认值。
示例：提取邮箱域名，若格式非法则返回 'unknown'
SELECT
CASE
WHEN ARRAY_LENGTH(REGEXP_SPLIT_TO_ARRAY(email, '@'), 1) >= 2
THEN SPLIT_PART(email, '@', 2)
ELSE 'unknown'
END AS domain
FROM (VALUES ('user@example.com'), ('no-at-symbol'), ('@missing-local')) t(email);
这里用了 REGEXP_SPLIT_TO_ARRAY 而非 SPLIT_PART 做长度判断，是因为 SPLIT_PART 无法告诉你总共分了几段——它只负责取某一段。
- 不要依赖
SPLIT_PART自身做边界判断；它不报错也不提示越界 - 对用户输入或不可信数据，建议先用
STRPOS或正则预检分隔符是否存在 - 如果 N 是变量（比如来自参数或另一列），确保它已 cast 为
integer，否则会报类型错误
替代方案：什么时候不该用 SPLIT_PART？
当你要提取的字段本身含分隔符（如 CSV 中带引号的逗号）、或需处理嵌套结构、或要遍历所有子串时，SPLIT_PART 就力不从心了。
典型场景：
- 解析 CSV 行：用
REGEXP_SPLIT_TO_TABLE+WITH ORDINALITY更可靠 - 提取 JSON 字段：直接用
->>或jsonb_extract_path_text - 需要按顺序处理全部片段：用
STRING_TO_ARRAY得到数组后配合UNNEST
例如，想把 'a,b,c' 拆成三行并编号：
SELECT * FROM UNNEST(STRING_TO_ARRAY('a,b,c', ',')) WITH ORDINALITY;
比连写三次 SPLIT_PART 清晰得多，也更容易扩展。
真正难的不是怎么写对一个 SPLIT_PART，而是意识到它只适合简单、确定结构的单次提取——一旦逻辑变复杂，兜底成本和可读性下降得很快。
