这问题问到点子上了！确实，Unicode的总字符范围（U+0000到U+10FFFF）远超过16位能容纳的65536个值，C#是靠UTF-16编码机制，尤其是「代理对（Surrogate Pairs）」来解决这个矛盾的，下面给你拆解清楚：

核心前提：char是UTF-16编码单元，不是单个Unicode字符 #

首先要纠正一个常见误解：C#里的char（即System.Char）并不直接对应一个完整的Unicode字符，它本质是UTF-16编码中的一个16位编码单元。

1. 基本多语言平面（BMP）：单个char搞定 #

Unicode把字符分成了17个平面，其中第0平面（U+0000到U+FFFF）是基本多语言平面（BMP），包含了几乎所有常用的字符（比如中文、英文、日文、常用符号等）。这部分字符刚好能被16位完全覆盖，所以直接用一个char就能存储和表示。

2. 补充平面：用代理对组合表示 #

剩下的16个补充平面（U+10000到U+10FFFF）包含了一些不常用的字符、特殊符号（比如大部分Emoji、罕见文字、历史字符等），这些字符的码位超出了16位的范围，于是UTF-16设计了代理对机制：

• 用两个连续的char来表示一个补充平面的字符
• 第一个char是高代理项（High Surrogate），取值范围是U+D800到U+DBFF
• 第二个char是低代理项（Low Surrogate），取值范围是U+DC00到U+DFFF

这两个范围在BMP里是专门预留的，不会用来表示任何单独的有效字符，所以CLR能明确识别：当看到连续的高代理+低代理时，就知道这是一个完整的Unicode字符，而不是两个独立的字符。

举个实际例子 #

比如Emoji里的😀，它的Unicode码位是U+1F600，对应的UTF-16代理对是：

• 高代理项：U+D83D（对应C#里的char值'\uD83D'）
• 低代理项：U+DE00（对应C#里的char值'\uDE00'）

在C#字符串里，这个Emoji会被存储为两个char，但逻辑上是一个字符：

string smiley = "😀";
Console.WriteLine(smiley.Length); // 输出 2，因为是两个char编码单元
// 用StringInfo来获取实际的字符数
var info = new System.Globalization.StringInfo(smiley);
Console.WriteLine(info.LengthInTextElements); // 输出 1，因为是一个Unicode字符

3. CLR的辅助处理方法 #

C#的基础类库提供了一系列方法来正确处理代理对，避免把单个代理项当成有效字符：

• char.IsSurrogate(char c)：判断一个char是否是代理项的一部分
• char.IsHighSurrogate(char c)：判断是否是高代理项
• char.IsLowSurrogate(char c)：判断是否是低代理项
• StringInfo.GetTextElementEnumerator(string s)：迭代字符串中的每个完整Unicode字符（而不是每个char）

内容的提问来源于stack exchange，提问作者user4385532