C# 11+ 中原始字符串字面量用三个双引号 """ 包裹，结尾 """ 必须独占一行且左对齐，内部换行、引号、反斜杠均不转义；支持 $""" 插值但 { } 需写为 {{ }}。
原始字符串字面量怎么写（C# 11+）
C# 从 11 开始支持原始字符串字面量，用三个双引号 """ 包裹，内部换行、反斜杠、引号都不需要转义。它不是“三引号字符串”的别名，而是独立语法：开头必须是连续三个双引号，结尾也必须是连续三个双引号，且结尾的 """ 必须顶格（不能有空格或制表符），否则编译失败。
- 开头
""" 后可直接换行，缩进会被原样保留（包括空格和制表符），但首行内容从第一个换行后开始算
- 结尾
""" 必须独占一行、左对齐，否则报错 CS8951
- 中间所有字符（含
\n、"、\t、\）都按字面意思处理，不解析转义序列
string json = """{
"name": "Alice",
"tags": ["c#", "raw"]
}""";
嵌入 JSON 时怎么避免引号和换行问题
JSON 天然含双引号和多行结构，用普通字符串要疯狂转义；原始字符串直接解决——但要注意缩进和末尾 """ 的位置。
- 不要手动拼接
"\"" 或用 @"" + 换行，那还是得处理引号冲突
- 如果 JSON 需要缩进对齐（比如调试输出），把整个 JSON 写在
""" 块里，靠编辑器自动缩进，但结尾 """ 必须顶格
- 若 JSON 要动态插入变量，原始字符串本身不支持插值；得用
$"""..."""，但此时 { 和 } 仍需转义为 {{ 和 }} 才能字面输出
string name = "Bob";
string payload = $"""{{
"user": "{name}",
"active": true
}}"""; // 注意 {{ 和 }} 是为了输出单个 { 和 }
写 SQL 查询时原始字符串比 @"" 更可靠的原因
SQL 经常含单引号、换行、缩进、甚至 T-SQL 的方括号 [ 和 ]，@"" 字符串虽免转义反斜杠，但仍会把换行当空格处理（影响可读性），且无法自然表达多行对齐；原始字符串则完全保留格式。
-
@"" 里写多行 SQL，每行末尾的换行会被当作空格，可能意外破坏 SQL 语义（如 WHERE\nid = 1 变成 WHERE id = 1，看似没问题，但嵌套 CTE 或注释时易出错）
- 原始字符串中换行就是换行，缩进就是缩进，SQL 引擎看到什么，你就写了什么
- 使用场景：EF Core 的
FromSqlRaw、Dapper 的 connection.Query、或任何需要字面 SQL 字符串的地方
string sql = """SELECT u.Name, COUNT(o.Id)
FROM Users AS u
LEFT JOIN Orders AS o ON u.Id = o.UserId
GROUP BY u.Name
ORDER BY COUNT(o.Id) DESC""";
常见错误和兼容性陷阱
原始字符串不是万能的，C# 11 是硬门槛，旧项目升级前务必确认 SDK 和目标框架版本。
- 错误现象：VS 提示
Feature 'raw string literals' is not available in C# 10 → 检查项目文件是否设置了 11.0
- 错误现象：编译报
CS8951: Raw string literal delimiter must be on its own line → 结尾 """ 前有空格、制表符，或跟在代码后面（如 """ + "abc"）
- 不要混用
@"" 和 """：比如 @""" 是非法语法，"""@"" 也没意义
- 跨平台路径拼接别依赖原始字符串：虽然
"""C:\temp\file.txt""" 看似方便，但 Windows-only；应优先用 Path.Combine
""" 后可直接换行，缩进会被原样保留（包括空格和制表符），但首行内容从第一个换行后开始算""" 必须独占一行、左对齐，否则报错 CS8951
\n、"、\t、\）都按字面意思处理，不解析转义序列""" 的位置。
- 不要手动拼接
"\""或用@""+ 换行，那还是得处理引号冲突 - 如果 JSON 需要缩进对齐（比如调试输出），把整个 JSON 写在
"""块里，靠编辑器自动缩进，但结尾"""必须顶格 - 若 JSON 要动态插入变量，原始字符串本身不支持插值；得用
$"""..."""，但此时{和}仍需转义为{{和}}才能字面输出
string name = "Bob";
string payload = $"""{{
"user": "{name}",
"active": true
}}"""; // 注意 {{ 和 }} 是为了输出单个 { 和 }
写 SQL 查询时原始字符串比 @"" 更可靠的原因
SQL 经常含单引号、换行、缩进、甚至 T-SQL 的方括号 [ 和 ]，@"" 字符串虽免转义反斜杠，但仍会把换行当空格处理（影响可读性），且无法自然表达多行对齐；原始字符串则完全保留格式。
-
@"" 里写多行 SQL，每行末尾的换行会被当作空格，可能意外破坏 SQL 语义（如 WHERE\nid = 1 变成 WHERE id = 1，看似没问题，但嵌套 CTE 或注释时易出错）
- 原始字符串中换行就是换行，缩进就是缩进，SQL 引擎看到什么，你就写了什么
- 使用场景：EF Core 的
FromSqlRaw、Dapper 的 connection.Query、或任何需要字面 SQL 字符串的地方
string sql = """SELECT u.Name, COUNT(o.Id)
FROM Users AS u
LEFT JOIN Orders AS o ON u.Id = o.UserId
GROUP BY u.Name
ORDER BY COUNT(o.Id) DESC""";
常见错误和兼容性陷阱
原始字符串不是万能的，C# 11 是硬门槛，旧项目升级前务必确认 SDK 和目标框架版本。
- 错误现象：VS 提示
Feature 'raw string literals' is not available in C# 10 → 检查项目文件是否设置了 11.0
- 错误现象：编译报
CS8951: Raw string literal delimiter must be on its own line → 结尾 """ 前有空格、制表符，或跟在代码后面（如 """ + "abc"）
- 不要混用
@"" 和 """：比如 @""" 是非法语法，"""@"" 也没意义
- 跨平台路径拼接别依赖原始字符串：虽然
"""C:\temp\file.txt""" 看似方便，但 Windows-only；应优先用 Path.Combine
@"" 里写多行 SQL，每行末尾的换行会被当作空格，可能意外破坏 SQL 语义（如 WHERE\nid = 1 变成 WHERE id = 1，看似没问题，但嵌套 CTE 或注释时易出错）FromSqlRaw、Dapper 的 connection.Query、或任何需要字面 SQL 字符串的地方- 错误现象：VS 提示
Feature 'raw string literals' is not available in C# 10→ 检查项目文件是否设置了11.0 - 错误现象：编译报
CS8951: Raw string literal delimiter must be on its own line→ 结尾"""前有空格、制表符，或跟在代码后面（如""" + "abc"） - 不要混用
@""和"""：比如@"""是非法语法，"""@""也没意义 - 跨平台路径拼接别依赖原始字符串：虽然
"""C:\temp\file.txt"""看似方便，但 Windows-only；应优先用Path.Combine
原始字符串的“原始”只作用于字符串内容本身，不改变编译期行为、不绕过注入防护、也不自动处理编码或 SQL 参数化——该用参数的地方，一个都不能少。
