SPLIT_PART在PostgreSQL 15中仍是轻量高效的字符串截取首选，但仅返回指定位置子串，不支持通配、越界报错或空字段处理；越界返回空字符串易致隐性bug，需用NULLIF或预检长度防御；多字符分隔符可行但不支持正则与NULL分隔符；结构不稳定时应改用string_to_array或正则函数。
SPLIT_PART 在 PostgreSQL 15 中仍是轻量、高效、无依赖的字符串截取首选，但必须注意它只返回单个位置的子串，不支持通配、越界静默、也不处理空字段逻辑。
什么时候该用 SPLIT_PART 而不是数组函数
当你明确知道目标字段在分隔后的位置（比如“永远取第2段”），且原始字符串格式稳定时，SPLIT_PART 比 string_to_array + array_position 或正则函数快 2–3 倍，执行计划里没有函数嵌套开销。
- 适合场景：解析固定结构日志（
'2026-09-06|INFO|User login'）、标准化 CSV 字段、路径层级（'/api/v1/users'取v1）、数据库导出字段拼接值 - 不适合场景：字段数不固定、需遍历所有片段、要过滤或去重、分隔符本身含转义（如
','出现在引号内） - PostgreSQL 15 没改变其行为——仍不支持负数 position（如
-1表示末尾），也不支持NULL作为 delimiter 参数
SPLIT_PART 的 position 越界会返回空字符串，不是报错
这是最容易被忽略的隐性 bug 来源。例如：SPLIT_PART('a,b', ',', 5) 返回 ''（空字符串），而不是 NULL 或报错。如果你后续用 WHERE col = 'expected' 判断，这个空串会导致条件恒假，查不到数据却无提示。
- 安全写法是显式检查长度：先用
array_length(string_to_array(str, delim), 1)判断是否足够长，再调SPLIT_PART - 或者用
NULLIF(SPLIT_PART(...), '')把空串转成NULL，方便后续IS NOT NULL判断 - 特别注意：当 delimiter 是空格或制表符时，开头/结尾连续空白会导致空段，
SPLIT_PART(' a b ', ' ', 1)实际返回空串，不是'a'
处理多字符分隔符和特殊符号的坑
SPLIT_PART 的 delimiter 参数是纯文本匹配，不支持正则、不支持转义序列（如 '\t'），传入什么就按字面意思切。这意味着：
- 想按制表符切？必须写
E'\t'（带E前缀的逃逸字符串），直接写'\t'会被当两个字符\和t - 分隔符是
'~^~'这种多字符组合？完全没问题，SPLIT_PART('x~^~y~^~z', '~^~', 2)正确返回'y' - 但 delimiter 不能为
NULL，否则整个函数返回NULL；也不能是空字符串''，否则报错：ERROR: zero-length delimiter
替代方案选型建议：别硬扛一个函数到底
当需求超出 SPLIT_PART 能力边界时，立刻切换更合适的工具：
- 需要全部片段 → 用
string_to_array(str, delim)，返回text[]，再配合unnest()或数组下标访问 - 分隔符不统一（如同时有
,和;）→ 改用regexp_split_to_array(str, '[,;]') - 要判断某值是否在分割结果中（如“标签包含 ‘post’”）→ 直接用
string_to_array(tags, ',') @> ARRAY['post']，比多次SPLIT_PART安全得多 - 想取最后一个字段（如文件扩展名）→ 不要用复杂计算 position，改用
reverse(split_part(reverse(str), delim, 1))，或更稳的split_part(str, delim, array_length(string_to_array(str, delim), 1))
真正难的从来不是怎么写对一行 SPLIT_PART，而是从一开始就想清楚：这个字符串的结构是否真的稳定、可预测。一旦出现任意一环不可控（用户输入、第三方日志格式变更、空字段容忍度低），就该放弃它，换数组或正则方案。
