string_agg必须显式处理null和排序：用isnull/coalesce转换null，且必须within group(order by ...)指定顺序；分隔符不可为null；不可在insert...values中直接嵌套；不支持distinct和空字符串过滤。
STRING_AGG在存储过程中必须显式处理NULL和排序
直接写 STRING_AGG(col, ',') 得到的结果不可靠：NULL值会被整行跳过（不是变成空字符串，是彻底消失），且聚合顺序完全随机。业务上常误以为“没ORDER BY就按插入顺序”，实际SQL Server不保证任何默认顺序。
正确做法是两件事必须一起做：
- 用
ISNULL(col, '(null)')或COALESCE(col, '')把NULL转成可控值 - 把排序写进函数内部：
STRING_AGG(ISNULL(col, ''), ',') WITHIN GROUP (ORDER BY id DESC)—— 外层ORDER BY对拼接结果无效 - 分隔符不能为NULL；SQL Server 2017不支持
SEPARATOR ''语法，空分隔符直接写''
不能在INSERT … VALUES里直接嵌套STRING_SPLIT或STRING_AGG
常见错误是想把拆分结果塞进单行INSERT：比如写 INSERT INTO t(col) VALUES (SELECT value FROM STRING_SPLIT(@s, ','))，这会报错“子查询返回多行”。STRING_AGG同理，它返回标量，不能当表用。
正确路径只有两条：
- 拆分后插入：用
INSERT INTO t(col) SELECT value FROM STRING_SPLIT(@s, ',') - 聚合后更新：先查出结果存变量，再用
SET @out = (SELECT STRING_AGG(...))，注意子查询必须只返回一行一列 - 别在同一个SELECT里混用STRING_AGG和窗口函数做排序依据，容易触发编译错误
去重、空字符串、数组字段这些场景STRING_AGG不直接支持
STRING_AGG本身不支持DISTINCT，也不处理字段值为空字符串''的情况——它只跳NULL，不跳空串，结果会出现北京,,上海这种冗余分隔符。
应对方式很具体：
- 去重要套一层子查询：
SELECT STRING_AGG(val, ',') FROM (SELECT DISTINCT val FROM @t) t - 空字符串转NULL再聚合：
STRING_AGG(CASE WHEN col = '' THEN NULL ELSE col END, ',') - 如果源字段是JSON或逗号拼接的字符串（如
'a,b,c'），得先用STRING_SPLIT展开成行，再聚合，不能直接STRING_AGG原字段
别和STUFF+FOR XML PATH混用，版本兼容性会当场翻车
有人想“保险起见”在存储过程中加IF @@VERSION LIKE '%2017%'判断再调STRING_AGG，但SQL Server在编译阶段就会检查所有分支里的语法——只要存在STRING_AGG，2016及更早版本直接编译失败，根本走不到运行时判断。
真实项目中要么统一用STUFF((SELECT ',' + col FROM t FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)'), 1, 1, '')（注意必须加TYPE和.value()防XML转义），要么确认全环境是2017+再全面切STRING_AGG。
最易被忽略的一点：STRING_AGG的分隔符是强制位置参数，漏写或传NULL会报错，而很多人复制示例时删掉了逗号后面的引号内容，导致存储过程创建就失败。
