cross apply 是唯一能动态传入左表字段调用 string_split 的方式，必须配合别名使用；需用 trim() 和 nullif() 处理空格与空值，sql server 2022+ 启用 enable_ordinal=1 可保序，多字符分隔符需 replace 转换单字符，结构化数据应优先用 openjson 或 xml 解析。
CROSS APPLY 必须配合 STRING_SPLIT，不能直接塞进子查询里用
很多人想在 WHERE 或 SELECT 中直接写 WHERE tag IN (SELECT value FROM STRING_SPLIT(t.tags, ','))，语法上不报错，但一旦 t.tags 来自左表字段（比如 products.tags），SQL Server 就会抛出“无法绑定多部分标识符”——因为子查询看不见外部表的列。真正能动态传入字段的，只有 CROSS APPLY 或 OUTER APPLY。
-
STRING_SPLIT返回的是表值函数结果，不是标量，所以不能当表达式用 - 必须写成
CROSS APPLY STRING_SPLIT(t.tags, ',') AS s，且AS s别名不能省，否则提示Incorrect syntax near '(' - 若要保留原始顺序（比如第2个标签必须是 priority），得用 SQL Server 2022+ 并启用
enable_ordinal = 1参数：STRING_SPLIT(t.tags, ',', 1)，再按s.ordinal排序
TRIM() 和 NULLIF() 是拆分后匹配前的必做动作
逗号分隔字符串里夹空格太常见了：'urgent , high , low' 拆出来是 'urgent '、' high '、' low'。直接 WHERE s.value = 'urgent' 会漏掉所有结果。
- 必须显式加
TRIM(s.value)，不能依赖 ANSI_PADDING 或默认行为 - 连续分隔符（如
'a,,b'）会产生空字符串，STRING_SPLIT不过滤它，得补WHERE NULLIF(TRIM(s.value), '') IS NOT NULL - 如果字段本身可能为 NULL，
CROSS APPLY会跳过整行；需要保留原行就换OUTER APPLY，但记得判s.value IS NOT NULL
多字符分隔符或嵌套结构得绕开 STRING_SPLIT
STRING_SPLIT 只支持单字符分隔符。遇到 'a|b||c' 或 JSON 风格的 '{"name":"x","val":"y"}'，硬用它只会把 || 当两个单 | 处理，产生错误空行。
- 分隔符是固定多字符（如
'::'），先用REPLACE转成单字符：REPLACE(t.data, '::', '|')，再喂给STRING_SPLIT - 结构化文本（XML/JSON）优先用原生解析函数：
OPENJSON()或nodes()，比字符串截取更稳 - 旧版本 SQL Server（2016 之前）只能靠循环函数或递归 CTE，性能差，且需手动处理边界（如末尾无分隔符）
顺序、空格、NULL、分隔符长度——这四个点漏掉任何一个，拆出来的数据就不可信。尤其 TRIM() 容易被当成“可选优化”，但它其实是匹配准确性的前提。
