STRING_SPLIT必须配合CROSS APPLY使用，不可裸用在WHERE或SELECT中；需校验输入非空、分隔符为单字符、结果需手动清洗去空格和空值。
STRING_SPLIT必须配合CROSS APPLY，不能裸用在WHERE或SELECT中
直接写 WHERE id IN (SELECT value FROM STRING_SPLIT(@input, ',')) 看似简洁，但一旦 @input 为空、NULL 或含空格，结果集就为空，整个 IN 判断变成逻辑假——查不到任何数据，且不报错，极难排查。更糟的是，若想把左表字段动态传入（比如 STRING_SPLIT(t.tags, ',')），子查询根本无法引用外部列，会报“无法绑定多部分标识符”。
正确姿势是强制用 CROSS APPLY，它天然支持左侧行值注入右侧函数：
SELECT u.name, s.value AS role FROM users u CROSS APPLY STRING_SPLIT(u.role_list, ',') s WHERE TRIM(s.value) = 'admin';
-
STRING_SPLIT必须带别名（如AS s），否则语法报错 - 右侧不能是括号包着的子查询，必须是函数调用或表值表达式
- 若用
OUTER APPLY，当@input为 NULL 时会保留左表行，值为NULL；CROSS APPLY则直接过滤掉该行
输入参数必须提前校验 NULL 和空字符串
STRING_SPLIT(NULL, ',') 返回空结果集，STRING_SPLIT('', ',') 同样返回空——两者都不报错，但后续 JOIN 或 INSERT 会静默丢数据。尤其当存储过程被其他系统调用时，前端可能传空串或全空格字符串。
务必在 CROSS APPLY 前加守卫逻辑：
IF @input IS NULL OR LTRIM(RTRIM(@input)) = ''
BEGIN
RETURN;
END
- 用
LTRIM(RTRIM(@input))而非LEN(@input) = 0，因为' '的LEN是 3，但语义上仍是空 - 别依赖
ISNULL(@input, '')后直接进STRING_SPLIT，那只是掩盖问题，没解决空逻辑分支 - 若业务允许“空输入代表全量”，则显式走另一条路径，不要让
STRING_SPLIT承担语义判断
分隔符只能是单字符，多字符会直接报错
传 ',' 没问题，传 ', '（逗号+空格）或 '|'（竖线）也没问题——但前提是它真是单个字符。若变量 @sep 实际值是 '| '（长度为2），SQL Server 会立刻抛出：Msg 214, Level 16, State 2, Procedure STRING_SPLIT: Parameter '@separator' must be a single-character string.
安全做法是强制截取首字符：
DECLARE @safe_sep CHAR(1) = SUBSTRING(@sep, 1, 1); -- 再用于 STRING_SPLIT(@input, @safe_sep)
- 别用
LEFT(@sep, 1)，因为LEFT对 NULL 返回 NULL，而SUBSTRING对 NULL 返回 NULL，行为一致 - 若业务明确只接受特定分隔符（如仅逗号或仅竖线），应在调用方校验，而非在存储过程中兜底
- 空字符串作为分隔符会被当作 NULL 处理，同样返回空结果集
拆分后要清洗、去重、保序？别指望STRING_SPLIT自动做
STRING_SPLIT 是纯机械切分器：连续分隔符产生空行（'a,,b' → 'a'、''、'b'），首尾空格原样保留（' a , b ' → ' a '、' b '），也不去重、不排序、不转类型。
常见清洗动作必须手动加：
SELECT
TRIM(s.value) AS clean_val,
ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS pos
FROM STRING_SPLIT(@input, ',') s
WHERE TRIM(s.value) '';
-
TRIM()在 SQL Server 2017+ 可用；老版本用RTRIM(LTRIM(s.value)) -
ROW_NUMBER()仅能模拟顺序，不能还原原始位置（SQL Server 2022+ 才有ordinal参数） - 要去重必须套一层
DISTINCT或GROUP BY，STRING_SPLIT本身不支持 - 若需强类型（如把
'123'转成INT），用TRY_CAST(s.value AS INT)，别用CAST——后者遇到非法值直接中断
实际用的时候，最常被忽略的是：你拿到的 value 列永远是 NVARCHAR(4000)，哪怕输入是 NVARCHAR(MAX)。超长项会被无声截断。 如果业务里真有 >4000 字符的单个元素，得先 CAST 输入为 NVARCHAR(MAX) 再传入——但 SQL Server 2022+ 才真正支持 NVARCHAR(MAX) 输出。
