char(10)是换行符（lf），char(13)是回车符（cr），windows下需组合使用char(13)+char(10)才能正确换行；单独使用可能不渲染或显示异常，ssms中需“以文本显示”才可见效果。
CHAR(10) 和 CHAR(13) 在 SQL Server 里到底怎么用
SQL Server 的 CHAR() 函数能返回指定 ASCII 码对应的字符，但直接拼进字符串时，换行往往“看不见”——不是函数没生效，而是客户端（比如 SSMS）默认不渲染换行符为视觉换行。真正起作用的是 CHAR(10)（换行 Line Feed，LF）和 CHAR(13)（回车 Carriage Return，CR），Windows 风格换行需要两者组合：CHAR(13) + CHAR(10)。
常见错误是只用 CHAR(10)，结果在某些工具里显示为方块或空格；或者误以为 CHAR(13) 单独就能换行，其实它只是把光标移到行首，不换行。
- 插入时：用
CONCAT('第一行', CHAR(13), CHAR(10), '第二行')或'第一行' + CHAR(13) + CHAR(10) + '第二行' - SELECT 查看效果：SSMS 默认关闭“结果以网格显示”时的换行渲染，建议右键结果 → “在文本中显示”，或改用
PRINT输出（PRINT会原样换行） - 导出到 Excel 或应用层消费时，
CHAR(13)+CHAR(10)才被广泛识别为换行；纯CHAR(10)在 Linux/macOS 环境下可能够用，但在 SQL Server 生态里优先用双字符组合
CHAR() 插入其他不可见字符的典型场景
除了换行，CHAR(9)（制表符 Tab）、CHAR(0)（空字符，慎用）、CHAR(32)（空格，一般不用 CHAR() 生成）也有实际用途，但要注意副作用。
比如日志拼接时想对齐字段，用 CHAR(9) 比空格更可靠；但 CHAR(0) 会导致字符串截断（SQL Server 把它当 C 字符串结束符），CHAR(1) 到 CHAR(8)、CHAR(11)、CHAR(12)、CHAR(14)–CHAR(31) 多数无显示且可能干扰排序或比较。
-
CHAR(9)安全可用，适合简单对齐，但注意不同终端对 Tab 的宽度解释不一致 -
CHAR(0)绝对避免写入数据列——哪怕INSERT成功，后续LEN()、DATALENGTH()行为异常，LIKE匹配也可能失效 - 用
ASCII()反查已有字符串中的不可见字符：例如SELECT ASCII(SUBSTRING(col, 5, 1)) FROM t WHERE id = 1，能帮你定位脏数据来源
CHAR() 拼接字符串时的隐式转换陷阱
CHAR() 返回的是 char(1) 类型，跟 varchar 或 nvarchar 拼接时，SQL Server 会按数据类型优先级做隐式转换。如果左边是 nvarchar，右边 CHAR(10) 会被转成 nvarchar；但如果左边是 varchar，而你要拼的是中文等 Unicode 内容，就可能出乱码。
- 安全做法：统一用
NCHAR()替代CHAR()，例如NCHAR(13) + NCHAR(10)，尤其当目标列是nvarchar时 - 避免混用：不要写
'中文' + CHAR(13) + CHAR(10) + '英文'，应写成N'中文' + NCHAR(13) + NCHAR(10) + '英文' - 检查执行计划里的警告：如果看到“隐式转换”，说明类型不匹配，可能影响索引使用或性能
验证 CHAR() 是否真的生效的三步法
别只靠肉眼扫结果——很多情况下换行符存在，但没被渲染。得用可验证的方式确认。
- 用
DATALENGTH()查长度变化：比如DATALENGTH('a' + CHAR(13) + CHAR(10) + 'b')返回 4（两个字母 + 两个控制符），而纯'ab'是 2 - 用
REPLACE()替换成可见符号调试：SELECT REPLACE(REPLACE(@str, CHAR(13), '[CR]'), CHAR(10), '[LF]') - 导出为 .txt 文件再用记事本/Notepad++ 打开，真实换行会体现出来；VS Code 也能开启“显示所有字符”来查看
最易被忽略的是：即使 CHAR(13)+CHAR(10) 正确插入，在 SSMS 的“结果以网格显示”模式下仍不会换行——这不是数据问题，是显示设置。调成“以文本显示”或换工具验证，才能确认是不是真存进去了。
