STRING_AGG报错非因截断，而是版本或兼容级别不足：SQL Server需≥2017且数据库兼容级别≥140；若输入为非MAX类型（如varchar(50)），输出会被隐式截断为varchar(8000)/nvarchar(4000)，应显式转为NVARCHAR(MAX)避免丢内容。
STRING_AGG 不会截断，报错一定是别的原因——最常见的是数据库兼容级别太低或版本不支持。
为什么 STRING_AGG 报错但没提示“截断”？
STRING_AGG 本身没有长度限制，也不会静默截断。所谓“截断报错”，其实是误判：真实错误通常是 Invalid object name 'STRING_AGG' 或 'STRING_AGG' is not a recognized built-in function name。这些根本不是截断问题，而是函数压根不可用。
- SQL Server 2016 及更早版本（兼容级别
130）完全不识别STRING_AGG，调用即报错 - 即使实例是 SQL Server 2019，若数据库兼容级别仍为
130或120，STRING_AGG仍不可用 -
WITHIN GROUP子句在兼容级别140（SQL Server 2017）以下直接语法报错，哪怕函数名能认出来
怎么快速确认是不是兼容级别问题？
别猜，直接查。两条命令必须一起执行：
-
SELECT SERVERPROPERTY('ProductVersion')—— 看主版本号是否 ≥14.0（2017）、15.0（2019）或16.0（2022） -
SELECT DATABASEPROPERTYEX(DB_NAME(), 'CompatibilityLevel')—— 结果必须 ≥140才能用STRING_AGG+WITHIN GROUP
如果第二条返回 130，立刻执行：ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 140（或更高）。注意：需 db_owner 权限，且不能在只读数据库上运行。
真遇到结果“变短”或“丢内容”，其实是隐式转换或类型截断
当 STRING_AGG 的输入表达式是 varchar(50) 或 nvarchar(100) 这类非 MAX 类型时，SQL Server 会按规则截断输出长度：
- 输入是
varchar(n)（n ≤ 8000），结果类型为varchar(8000)，超长部分被无声截掉 - 输入是
nvarchar(n)（n ≤ 4000），结果类型为nvarchar(4000)，同样会截断 - 数字、日期等非字符串类型默认转成
nvarchar(4000)，一旦拼接后总长超 4000 字符，就丢尾部
解决办法统一：把输入显式转成 MAX 类型。例如：STRING_AGG(CONVERT(NVARCHAR(MAX), name), ', ') WITHIN GROUP (ORDER BY id)。别依赖隐式转换，也别用 CAST(name AS NVARCHAR)（缺长度声明等于 NVARCHAR(30)）。
别把 FOR XML PATH 的坑当成 STRING_AGG 的问题
很多团队从 FOR XML PATH('') 迁移过来，一出问题就怀疑 STRING_AGG。但二者行为差异极大：
-
FOR XML会把&、、<code>>自动转义成&、、<code>>，而STRING_AGG原样输出 -
FOR XML在空结果时返回空字符串，STRING_AGG在无行时返回NULL——这常导致应用层 NRE（NullReferenceException） -
FOR XML没有原生排序能力，靠子查询ORDER BY实现；STRING_AGG必须用WITHIN GROUP，漏写就报错
迁移时最容易忽略的，是把原来 STUFF(..., 1, 1, '') 的容错逻辑，直接套到 STRING_AGG 上——它不需要去首逗号，也不怕空结果崩掉。
