在.NET里写代码大概率没人敢说自己没用过string。字符串太常用了以至于很多人把它当成一种“基本类型”但面试一被问到String类的底层存储和编码就开始卡壳string明明是引用类型为什么比较起来像值类型它在堆上到底怎么放为什么说它是不可变的如果你也有这些疑问这篇文章围绕存储、编码、不可变性三个核心维度展开结合我这些年调乱码、查内存、改拼接逻辑时踩过的坑一次讲透。无论你是刚接触C#的新手还是被线上问题折磨过一阵子的老开发都应该能从中找到点东西。1. 字符串存储模型拆解一个string对象在内存里到底长什么样1.1 引用类型、堆分配、内联字符数组C#里的string是用sealed class定义的典型引用类型。这意味着声明string s Hello时栈上的s只是一个指向托管堆的引用真正保存字符数据的对象在堆上。这一点足够基础但很多人第一次听到“字符串是引用类型”时会愣一下因为在日常使用中它根本看不出引用类型的痕迹——复制一个变量、传给方法似乎都是按值在传内容。真正想理解存储得看String对象在堆上的布局。和大多数引用类型不同string对象没有单独指向一个char[]的字段而是把字符数据直接内联在对象体里大致可以画成下面这样[同步块索引][方法表指针][字符串长度(int)][char字符数据……]64位环境下对象头同步块索引方法表指针长度字段大约20字节左右再加上对齐一个空字符串差不多要占26字节。之后每多一个字符就多2字节因为内部每个char都是UTF-16 code unit。也就是说一个char固定16位无论它是英文字母还是中文汉字在.NET字符串内部占的字节数一模一样。这种设计是有讲究的。如果字符串内部存的是byte[]或char[]的引用访问字符就要多一次寻址缓存局部性也差。现在是直接把数据“焊”在对象后面s[0]的索引在JIT里能优化成非常快的内存读取。配合不可变性所有引用可以放心共享同一份数据根本不需要拷贝。这也是为什么把字符串传进方法几乎零成本——你传的只是对象引用而对象内容永远不会被改。1.2 Length数的是char不是“字符”也不是“字节”接下来是一个超级常见的认知误区。s.Length返回的是UTF-16代码单元的数量在.NET里就是char的数量不代表用户看到的字符数更不代表字节数。比如AB这个字符串Length是4而不是3。因为U1F600超出了基本多语言平面BMPUTF-16拿一个char装不下需要用代理对一个高代理char加一个低代理char两个16位单元才能表示一个完整码点。这个细节写业务代码时不太容易踩但一旦涉及字符串遍历、截断、按长度校验就会出问题。比如手机号、姓名这类输入用Length限制长度对emoji不友好日志里截断字符串时如果把代理对从中间切断后面就是残的。需要按用户可感知字符处理时别自己数char用System.Globalization.StringInfo或直接枚举Runestring text AB; Console.WriteLine(text.Length); // 4 Console.WriteLine(char.IsSurrogatePair(text[1], text[2])); // True foreach (Rune rune in text.EnumerateRunes()) Console.WriteLine(rune.Value); // 65, 128512, 66顺带一提Rune是.NET 5以后引入的结构专门表示一个Unicode标量值。用Rune处理用户文本比手搓代理对稳得多。以前写字符串逆序要考虑代理对现在直接用Rune逐字处理我强烈建议字符串处理类代码优先用它。1.3 字符串驻留池内容相同的字面量只存一份聊存储就绕不开字符串驻留Interning。CLR内部维护着一张哈希表叫驻留池。编译期能确定的字符串字面量在程序集里只存一份CLR加载后放进驻留池之后代码里再出现相同内容的字面量直接复用同一个实例。所以下面这段代码引用相等是Truestring s1 hello; string s2 hello; Console.WriteLine(ReferenceEquals(s1, s2)); // True运行期动态拼出来的字符串默认不会自动驻留。比如new string(new[] {h,e,l,l,o})和hello内容一样引用却不同。想手动进池可以调string.Intern(s3)。另外编译期常量折叠的字符串也会进池比如string s5 a b;在编译后就是字面量ab和直接写ab是完全一样的。驻留池的价值是省内存。一个进程里如果反复出现几千个相同内容的状态字符串、错误码驻留能显著降低重复分配。但驻留池有一个非常坑的特性进去的字符串永远留在池里GC不会回收。所以动态生成的、取值空间很大的字符串绝对不要Intern否则等于给自己造内存泄漏。我生产环境的经验是只有取值范围有限、重复率极高且总量可控的字符串才值得驻留比如订单状态、枚举名映射用户输入、请求参数一次都不要。2. 编码模型深度解析内存里是UTF-16外面却是另一个世界2.1 为什么.NET偏偏选择UTF-16讲编码之前先把一个容易混淆的事实钉死.NET字符串在内存中的编码永远是UTF-16每个char 16位。不是UTF-8也不是GBK。你看到的Encoding.UTF8.GetBytes、数据库里的varchar都是把字符串转换成外部字节流时的动作和String对象在内存里怎么存没有关系。为什么选UTF-16主要是历史原因。Windows NT系列和COM/BSTR从一开始就是UTF-16.NET要跟原生代码互操作用UTF-16可以少一层转换。这也是为什么char类型恰恰是16位、为什么Encoding.Unicode默认指的是UTF-16LE——Windows生态里的“Unicode”通常就是指UTF-16LE。在BMP基本多语言平面范围内UTF-16是定长的索引和长度计算都很直接。今天回头看UTF-8在存储和传输上更省字节尤其ASCII场景但这是二十多年前的设计选择核心模型一旦定下来想改就是天文数字的兼容性成本。2.2 代理对、Rune与Unicode补充字符UTF-16定长只在BMP范围内成立。Unicode码点范围是0到0x10FFFF超出BMP、落入补充平面的字符UTF-16必须用代理对表示。高代理范围UD800到UDBFF低代理范围UDC00到UDFFF。有个很直观的例子char.ConvertFromUtf32(0x1F600)得到的是两个char而不是一个string emoji char.ConvertFromUtf32(0x1F600); // Console.WriteLine(emoji.Length); // 2 Console.WriteLine(char.IsHighSurrogate(emoji[0])); // True Console.WriteLine(char.IsLowSurrogate(emoji[1])); // True // 反向还原码点 int cp char.ConvertToUtf32(emoji, 0); Console.WriteLine(cp); // 128512代理对的存在让很多“看似很对”的代码变得危险。比如倒序遍历字符串、用Substring按位置截断、按Length计算展示宽度遇到emoji或生僻字都可能翻车。稳妥做法是用Rune枚举或StringInfo处理文本元素。如果你在做聊天消息、评论、文件名词条这类可能包含各种emoji的功能建议先跑一遍代理对测试再谈上线。2.3 编码转换实操字符串转为字节再转回来字符串和字节流的关系一句话总结字符串是抽象的字符序列字节流是它在某种编码下的具体表达。同一个字符串UTF-8、UTF-16、GB18030编码出来的字节串完全不同。转换核心就是Encoding类最常见的代码是byte[] utf8Bytes Encoding.UTF8.GetBytes(text); string back Encoding.UTF8.GetString(utf8Bytes);只要“写进去”和“读出来”用同一套编码理论上就能原样还原。乱码的本质几乎都是两个环节编码不一致。常用的编码对象大概是这样编码对象.NET中的用法特点UTF-8Encoding.UTF8变长1-4字节兼容ASCII网络和文件传输最常用UTF-16 LEEncoding.UnicodeBMP内定长Windows/COM上的“Unicode”UTF-16 BEEncoding.BigEndianUnicode大端UTF-16少见但存在UTF-32Encoding.UTF32定长4字节处理码点最直接但占用大GB18030/GBKEncoding.GetEncoding(GB18030)中文Windows生态老系统文件常是这个重点说一个迁移坑在.NET Framework里Encoding.Default返回系统ANSI代码页中文Windows上就是GBK在.NET Core/.NET 5里Encoding.Default已经变成UTF-8。不少老项目从Framework迁到.NET 6后读出来的配置文件、CSV全部乱码十有八九是Encoding.Default语义变了。正确做法是从不依赖Default显式指定编码。另外.NET Core里默认没有GBK/GB2312想用要先注册代码页提供程序Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); Encoding gbk Encoding.GetEncoding(GB18030);还有BOMByte Order Mark。UTF-8带BOM是EF BB BFUTF-16LE带BOM是FF FE。BOM的作用是让读取方自动识别编码。StreamReader和File.ReadAllText会先看BOM决定解码方式没有BOM再用默认UTF-8。很多无BOM的GBK文件就这样被当成UTF-8读成了乱码。日常规范文件读写用UTF-8关键是通过配置让读取端知道你用的是哪个而不是赌默认值。3. 不可变性设计信仰与性能陷阱并存3.1 “修改字符串”只是换了个新对象string是不可变对象意思是创建之后对象内部的字符数据永远不可变。所有看起来在修改字符串的方法——ToUpper、ToLower、Replace、Trim、Substring、Remove、Insert——都是返回一个全新的字符串原对象动都没动。更直观的例子是string s hello; s , world;第二行并不是在原字符串后面追加而是先创建一个长度为12的新字符串把“hello, world”整体复制进去再让s指向这个新对象。原来的“hello”对象如果没有别的引用就被GC回收。编译器对字符串字面量拼接有常量折叠优化string a he llo;在编译期就合并成一个hello字面量运行期没有拼接。对运行时变量做则要看场景。.NET 6以后的字符串插值也做了重要升级编译器会把$Hello, {name}!转换成DefaultInterpolatedStringHandler的写法handler内部有点像StringBuilder的缓冲机制能复用缓冲区大量减少临时字符串分配。所以日常格式化字符串优先用插值而不是string.Format。3.2 为什么不可变线程安全、哈希缓存、放心传递有人会问设计成不可变是不是太死板恰恰相反这是整个框架最值钱的设计之一。不可变带来的第一个收益是线程安全。多个线程同时读同一个字符串没有任何写操作自然没有竞态。如果字符串可变字典的哈希键、配置开关、命令参数被某个线程改了整个世界都会乱套。第二是哈希缓存。字符串经常作为字典的key哈希值一旦算出来可以安全缓存因为内容不会变。如果字符串可变字典每次查找都要重新验证内容甚至哈希表结构都会被破坏。第三是引用可以放心到处传。你传一个字符串参数给方法不用怕方法内部把它改了你从方法返回一个字符串也不用担心调用方篡改。这种安全性让代码边界变得非常干净。可以拿合同类比一份不可篡改的合同原件你才敢放心把它同时交给很多部门传阅、存档。可变对象相当于每个人手上拿的都是同一份原件谁都能改一笔最后根本说不清楚哪份是对的了。3.3 拼接陷阱为什么循环里不要用不可变性的主要成本就是拼接。看一段典型代码string result ; for (int i 0; i 10000; i) { result i.ToString() ,; }每循环一次都会创建一个新的字符串对象把旧内容全部复制一遍再追加。10000次循环中间会创建大约两万个字符串对象GC会被迫频繁回收性能非常难看。这不是编译器能优化掉的因为每次循环长度都不确定。正确做法是用StringBuildervar sb new StringBuilder(); for (int i 0; i 10000; i) { sb.Append(i).Append(,); } string result sb.ToString();StringBuilder内部维护字符缓冲区Append直接在缓冲区里写空间不够就扩容只有最后ToString时才复制一次。这是为“反复修改字符串”这种场景量身定做的容器。但我还要泼一盆冷水不是所有拼接都用StringBuilder。两三次字符串相加直接或插值就好编译器可能还会走Concat优化刻意用StringBuilder反而代码臃肿。判断标准很简单拼接次数少、内容固定用在循环里拼、拼的量级大用StringBuilder。另外StringBuilder不是线程安全的多线程追加要注意同步。3.4 Substring会复制截取子串前先想清楚Substring是另一个高频操作。很多人误以为Substring只是“切一个视图”成本很低实际上它每次都会复制出新的字符串对象。当你只需要读一下子串内容却不断调用Substring时比如解析大文本、CSV、JSON会产生大量临时字符串。这时候应该用AsSpan避免分配ReadOnlySpanchar span text.AsSpan(start, length); // 直接使用 span 做解析、比较零分配Span是视图不复制字符数据处理完就没了。这个特性从.NET Core 2.1开始可用对解析类代码优化显著。但有一点要清楚如果截出来必须是一个独立的string比如作为字典key、放进列表那就只能接受Substring的复制成本。这是不可变现出来的必然结果——你不能把一个“视图”长期保存因为原始字符串可能已经被回收了。做性能优化时先问自己我要的是字符串本身还是只是暂时看一眼4. 实操过程一条完整的编码链路以及我踩过的三个坑4.1 从文件读取BOM、默认编码和GBK老文件先说我处理过的一个真实案例。客户给了一个CSVExcel导出的里面全是中文。我在.NET 6下直接File.ReadAllText(path)读出来全是乱码。查下来原因是文件没有BOM编码是GBK而File.ReadAllText在无BOM时默认按UTF-8解码——GBK和UTF-8对中文的字节布局完全不一样自然全乱。解决办法是显式指定编码Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); string content File.ReadAllText(path, Encoding.GetEncoding(GB18030));GB18030几乎兼容所有GBK/GB2312字符比用936更稳妥。如果是自己程序写日志、配置文件我强烈建议统一UTF-8并让写入端显式指定编码。读文件前先看BOM有BOM的优先让系统自动检测无BOM的最好通过配置或约定告诉读取端到底是什么编码。4.2 从网络和数据库接收字符串charset和连接串都有坑网络传输中最常见的乱码原因是响应头声明的charset和实际编码不一致。比如后端返回GBK数据Content-Type写utf-8前端把字节按UTF-8解必乱。.NET里用HttpClient拿响应内容时如果响应头没有明确charset很多实现会按一层默认编码解读遇到GBK接口就得手动处理byte[] raw await response.Content.ReadAsByteArrayAsync(); string text Encoding.GetEncoding(GB18030).GetString(raw);这是调老系统接口时经常用到的兜底写法。数据库同理。SQL Server的NVarChar/NText是UTF-16MySQL的utf8mb4是UTF-8连接字符串里的Charset参数要和表结构、客户端三方对齐。MySQL传回来乱码的案例我见过十次有八次是连接串漏了charsetutf8mb4或者表本身是latin1。4.3 控制台、日志和编码验证控制台乱码也高频尤其是Windows。C#控制台输出中文变成问号多半是控制台代码页不匹配。代码里设置一下Console.OutputEncoding Encoding.UTF8;日志输出建议统一UTF-8跨平台、跨工具都稳定。同一套日志Windows记事本按ANSI打开是GBK在Linux按UTF-8打开是乱码这类问题都是“没有显式统一编码”造成的。最后给一个自检用的最小闭环验证你的编码链路是否通畅string original 你好世界; byte[] utf8 Encoding.UTF8.GetBytes(original); string back Encoding.UTF8.GetString(utf8); Console.WriteLine(original back); // True把“写入编码”和“读出编码”固定下来整个链路就稳了。记住ASCII之外的文本绝不要用系统默认编码做存储或传输默认值在不同环境可能完全不同。5. 常见乱码问题与面试高频点速查5.1 中文乱码的三种特征与排查套路乱码不是玄学它是字节序列被错误解释的必然结果。看到“锟斤拷”通常是UTF-8的内容先用GBK解码再把得到的字符重新编码成UTF-8中间的替换符被GBK显示成了“锟斤拷”。看到“????”多半是目标编码字符集没有这个字符直接拿问号替代。看到一串“烫烫烫”那是没初始化内存的调试填充值不是编码问题。排查顺序记住这几步先拿到原始字节别在已经变成字符串的乱码上猜看有没有BOM有BOM基本能锁定无BOM就根据来源判断编码一般老系统是GBK/GB2312现代接口默认UTF-8用对应编码GetString如果对问题就出在“拿到的字符串已经在某个环节被错误解码过”。我经常跟团队说的一句话编码问题要在字节层面解决不要在字符层面瞎猜。一旦字符串在错误编码下被解码过一次再转回原编码就困难了因为信息已经丢了。所以写代码时传输、存储、读取三个环节的编码必须显式、统一、可配置。5.2 字符串比较、Equals、ReferenceEquals到底怎么选string是引用类型但被重载成了按值比较所以abc abc为true。Equals也按值比较。真正判断“是不是同一个对象”要用ReferenceEquals。驻留机制经常让人懵字面量相等的字符串ReferenceEquals也经常为true会给初学者造成“是引用比较”的错觉。实际开发里比较内容就用或string.Equals比较性能要求高时可以显式传StringComparison。大小写不敏感用StringComparison.OrdinalIgnoreCase它比CurrentCultureIgnoreCase更可控。注意culture相关的比较有时会让你大跌眼镜比如土耳其语环境下i.ToUpper()不是I而是带点的İ。国际化应用里比较字符串尽量用ordinal而非culture除非你确实需要本地化排序。5.3 面试高频题速查不可变、存储和编码一次讲清面试问题一句话回答string是值类型还是引用类型引用类型但被重载为按内容比较string为什么要不可变线程安全、哈希缓存安全、引用可放心共享为什么StringBuilder比循环高效拼接会创建大量不可变临时对象StringBuilder在缓冲区上追加字符串驻留是什么相同内容的字面量在CLR驻留池中复用同一实例s.Length是字符数吗是UTF-16代码单元数不是用户可见字符数不是字节数中文乱码的本质写入和读取用了不同的字符编码.NET里能用GBK吗.NET Core需要Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)如果面试官再往深问可以补一句Java的String同样不可变Java 9以后内部用byte[]加coder做紧凑存储.NET则是char数据内联在对象里。至于Java的StringBuffer那是在Java里用于线程安全字符串拼接的类.NET里并没有StringBuffer对应角色是StringBuilder很多从Java转C#的同事会混淆面试卡在这一下就能暴露基础。6. 最后几条我用真金白银换来的String使用心法纸上谈兵容易踩过坑才算数。我这些年调过最多的字符串问题不是性能而是编码。所以我的第一条心法是凡是读写文件、发HTTP请求、连数据库编码一定要显式写死绝不依赖环境默认值。团队代码规范里如果有这一条能挡掉一半以上的乱码工单。第二条不可变是保护不是限制。不要为了省内存去Intern用户输入也不要在循环里用拼大字符串。真到需要极致性能时用Span、用StringBuilder、用Rune但先搞清楚自己的瓶颈到底在不在字符串上。很多时候真正拖垮系统的不是字符串本身而是到处复制的中间结果。第三条小技巧如果需要对大量重复字符串做去重和复用我更倾向用Dictionarystring, string做显式缓存而不是string.Intern。字典缓存可控、可清、可统计命中和容量驻留池则是一条路走到黑。这个差异在长期运行的服务里非常明显。