在.NET里寫代碼大概率沒人敢說自己沒用過string。字符串太常用了以至于很多人把它當成一種“基本類型”但面試一被問到String類的底層存儲和編碼就開始卡殼string明明是引用類型為什么比較起來像值類型它在堆上到底怎么放為什么說它是不可變的如果你也有這些疑問這篇文章圍繞存儲、編碼、不可變性三個核心維度展開結(jié)合我這些年調(diào)亂碼、查內(nèi)存、改拼接邏輯時踩過的坑一次講透。無論你是剛接觸C#的新手還是被線上問題折磨過一陣子的老開發(fā)都應該能從中找到點東西。1. 字符串存儲模型拆解一個string對象在內(nèi)存里到底長什么樣1.1 引用類型、堆分配、內(nèi)聯(lián)字符數(shù)組C#里的string是用sealed class定義的典型引用類型。這意味著聲明string s Hello時棧上的s只是一個指向托管堆的引用真正保存字符數(shù)據(jù)的對象在堆上。這一點足夠基礎但很多人第一次聽到“字符串是引用類型”時會愣一下因為在日常使用中它根本看不出引用類型的痕跡——復制一個變量、傳給方法似乎都是按值在傳內(nèi)容。真正想理解存儲得看String對象在堆上的布局。和大多數(shù)引用類型不同string對象沒有單獨指向一個char[]的字段而是把字符數(shù)據(jù)直接內(nèi)聯(lián)在對象體里大致可以畫成下面這樣[同步塊索引][方法表指針][字符串長度(int)][char字符數(shù)據(jù)……]64位環(huán)境下對象頭同步塊索引方法表指針長度字段大約20字節(jié)左右再加上對齊一個空字符串差不多要占26字節(jié)。之后每多一個字符就多2字節(jié)因為內(nèi)部每個char都是UTF-16 code unit。也就是說一個char固定16位無論它是英文字母還是中文漢字在.NET字符串內(nèi)部占的字節(jié)數(shù)一模一樣。這種設計是有講究的。如果字符串內(nèi)部存的是byte[]或char[]的引用訪問字符就要多一次尋址緩存局部性也差?，F(xiàn)在是直接把數(shù)據(jù)“焊”在對象后面s[0]的索引在JIT里能優(yōu)化成非?？斓膬?nèi)存讀取。配合不可變性所有引用可以放心共享同一份數(shù)據(jù)根本不需要拷貝。這也是為什么把字符串傳進方法幾乎零成本——你傳的只是對象引用而對象內(nèi)容永遠不會被改。1.2 Length數(shù)的是char不是“字符”也不是“字節(jié)”接下來是一個超級常見的認知誤區(qū)。s.Length返回的是UTF-16代碼單元的數(shù)量在.NET里就是char的數(shù)量不代表用戶看到的字符數(shù)更不代表字節(jié)數(shù)。比如AB這個字符串Length是4而不是3。因為U1F600超出了基本多語言平面BMPUTF-16拿一個char裝不下需要用代理對一個高代理char加一個低代理char兩個16位單元才能表示一個完整碼點。這個細節(jié)寫業(yè)務代碼時不太容易踩但一旦涉及字符串遍歷、截斷、按長度校驗就會出問題。比如手機號、姓名這類輸入用Length限制長度對emoji不友好日志里截斷字符串時如果把代理對從中間切斷后面就是殘的。需要按用戶可感知字符處理時別自己數(shù)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以后引入的結(jié)構(gòu)專門表示一個Unicode標量值。用Rune處理用戶文本比手搓代理對穩(wěn)得多。以前寫字符串逆序要考慮代理對現(xiàn)在直接用Rune逐字處理我強烈建議字符串處理類代碼優(yōu)先用它。1.3 字符串駐留池內(nèi)容相同的字面量只存一份聊存儲就繞不開字符串駐留Interning。CLR內(nèi)部維護著一張哈希表叫駐留池。編譯期能確定的字符串字面量在程序集里只存一份CLR加載后放進駐留池之后代碼里再出現(xiàn)相同內(nèi)容的字面量直接復用同一個實例。所以下面這段代碼引用相等是Truestring s1 hello; string s2 hello; Console.WriteLine(ReferenceEquals(s1, s2)); // True運行期動態(tài)拼出來的字符串默認不會自動駐留。比如new string(new[] {h,e,l,l,o})和hello內(nèi)容一樣引用卻不同。想手動進池可以調(diào)string.Intern(s3)。另外編譯期常量折疊的字符串也會進池比如string s5 a b;在編譯后就是字面量ab和直接寫ab是完全一樣的。駐留池的價值是省內(nèi)存。一個進程里如果反復出現(xiàn)幾千個相同內(nèi)容的狀態(tài)字符串、錯誤碼駐留能顯著降低重復分配。但駐留池有一個非常坑的特性進去的字符串永遠留在池里GC不會回收。所以動態(tài)生成的、取值空間很大的字符串絕對不要Intern否則等于給自己造內(nèi)存泄漏。我生產(chǎn)環(huán)境的經(jīng)驗是只有取值范圍有限、重復率極高且總量可控的字符串才值得駐留比如訂單狀態(tài)、枚舉名映射用戶輸入、請求參數(shù)一次都不要。2. 編碼模型深度解析內(nèi)存里是UTF-16外面卻是另一個世界2.1 為什么.NET偏偏選擇UTF-16講編碼之前先把一個容易混淆的事實釘死.NET字符串在內(nèi)存中的編碼永遠是UTF-16每個char 16位。不是UTF-8也不是GBK。你看到的Encoding.UTF8.GetBytes、數(shù)據(jù)庫里的varchar都是把字符串轉(zhuǎn)換成外部字節(jié)流時的動作和String對象在內(nèi)存里怎么存沒有關(guān)系。為什么選UTF-16主要是歷史原因。Windows NT系列和COM/BSTR從一開始就是UTF-16.NET要跟原生代碼互操作用UTF-16可以少一層轉(zhuǎn)換。這也是為什么char類型恰恰是16位、為什么Encoding.Unicode默認指的是UTF-16LE——Windows生態(tài)里的“Unicode”通常就是指UTF-16LE。在BMP基本多語言平面范圍內(nèi)UTF-16是定長的索引和長度計算都很直接。今天回頭看UTF-8在存儲和傳輸上更省字節(jié)尤其ASCII場景但這是二十多年前的設計選擇核心模型一旦定下來想改就是天文數(shù)字的兼容性成本。2.2 代理對、Rune與Unicode補充字符UTF-16定長只在BMP范圍內(nèi)成立。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或生僻字都可能翻車。穩(wěn)妥做法是用Rune枚舉或StringInfo處理文本元素。如果你在做聊天消息、評論、文件名詞條這類可能包含各種emoji的功能建議先跑一遍代理對測試再談上線。2.3 編碼轉(zhuǎn)換實操字符串轉(zhuǎn)為字節(jié)再轉(zhuǎn)回來字符串和字節(jié)流的關(guān)系一句話總結(jié)字符串是抽象的字符序列字節(jié)流是它在某種編碼下的具體表達。同一個字符串UTF-8、UTF-16、GB18030編碼出來的字節(jié)串完全不同。轉(zhuǎn)換核心就是Encoding類最常見的代碼是byte[] utf8Bytes Encoding.UTF8.GetBytes(text); string back Encoding.UTF8.GetString(utf8Bytes);只要“寫進去”和“讀出來”用同一套編碼理論上就能原樣還原。亂碼的本質(zhì)幾乎都是兩個環(huán)節(jié)編碼不一致。常用的編碼對象大概是這樣編碼對象.NET中的用法特點UTF-8Encoding.UTF8變長1-4字節(jié)兼容ASCII網(wǎng)絡和文件傳輸最常用UTF-16 LEEncoding.UnicodeBMP內(nèi)定長Windows/COM上的“Unicode”UTF-16 BEEncoding.BigEndianUnicode大端UTF-16少見但存在UTF-32Encoding.UTF32定長4字節(jié)處理碼點最直接但占用大GB18030/GBKEncoding.GetEncoding(GB18030)中文Windows生態(tài)老系統(tǒng)文件常是這個重點說一個遷移坑在.NET Framework里Encoding.Default返回系統(tǒng)ANSI代碼頁中文Windows上就是GBK在.NET Core/.NET 5里Encoding.Default已經(jīng)變成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決定解碼方式?jīng)]有BOM再用默認UTF-8。很多無BOM的GBK文件就這樣被當成UTF-8讀成了亂碼。日常規(guī)范文件讀寫用UTF-8關(guān)鍵是通過配置讓讀取端知道你用的是哪個而不是賭默認值。3. 不可變性設計信仰與性能陷阱并存3.1 “修改字符串”只是換了個新對象string是不可變對象意思是創(chuàng)建之后對象內(nèi)部的字符數(shù)據(jù)永遠不可變。所有看起來在修改字符串的方法——ToUpper、ToLower、Replace、Trim、Substring、Remove、Insert——都是返回一個全新的字符串原對象動都沒動。更直觀的例子是string s hello; s , world;第二行并不是在原字符串后面追加而是先創(chuàng)建一個長度為12的新字符串把“hello, world”整體復制進去再讓s指向這個新對象。原來的“hello”對象如果沒有別的引用就被GC回收。編譯器對字符串字面量拼接有常量折疊優(yōu)化string a he llo;在編譯期就合并成一個hello字面量運行期沒有拼接。對運行時變量做則要看場景。.NET 6以后的字符串插值也做了重要升級編譯器會把$Hello, {name}!轉(zhuǎn)換成DefaultInterpolatedStringHandler的寫法handler內(nèi)部有點像StringBuilder的緩沖機制能復用緩沖區(qū)大量減少臨時字符串分配。所以日常格式化字符串優(yōu)先用插值而不是string.Format。3.2 為什么不可變線程安全、哈希緩存、放心傳遞有人會問設計成不可變是不是太死板恰恰相反這是整個框架最值錢的設計之一。不可變帶來的第一個收益是線程安全。多個線程同時讀同一個字符串沒有任何寫操作自然沒有競態(tài)。如果字符串可變字典的哈希鍵、配置開關(guān)、命令參數(shù)被某個線程改了整個世界都會亂套。第二是哈希緩存。字符串經(jīng)常作為字典的key哈希值一旦算出來可以安全緩存因為內(nèi)容不會變。如果字符串可變字典每次查找都要重新驗證內(nèi)容甚至哈希表結(jié)構(gòu)都會被破壞。第三是引用可以放心到處傳。你傳一個字符串參數(shù)給方法不用怕方法內(nèi)部把它改了你從方法返回一個字符串也不用擔心調(diào)用方篡改。這種安全性讓代碼邊界變得非常干凈?？梢阅煤贤惐纫环莶豢纱鄹牡暮贤悴鸥曳判陌阉瑫r交給很多部門傳閱、存檔?？勺儗ο笙喈斢诿總€人手上拿的都是同一份原件誰都能改一筆最后根本說不清楚哪份是對的了。3.3 拼接陷阱為什么循環(huán)里不要用不可變性的主要成本就是拼接。看一段典型代碼string result ; for (int i 0; i 10000; i) { result i.ToString() ,; }每循環(huán)一次都會創(chuàng)建一個新的字符串對象把舊內(nèi)容全部復制一遍再追加。10000次循環(huán)中間會創(chuàng)建大約兩萬個字符串對象GC會被迫頻繁回收性能非常難看。這不是編譯器能優(yōu)化掉的因為每次循環(huán)長度都不確定。正確做法是用StringBuildervar sb new StringBuilder(); for (int i 0; i 10000; i) { sb.Append(i).Append(,); } string result sb.ToString();StringBuilder內(nèi)部維護字符緩沖區(qū)Append直接在緩沖區(qū)里寫空間不夠就擴容只有最后ToString時才復制一次。這是為“反復修改字符串”這種場景量身定做的容器。但我還要潑一盆冷水不是所有拼接都用StringBuilder。兩三次字符串相加直接或插值就好編譯器可能還會走Concat優(yōu)化刻意用StringBuilder反而代碼臃腫。判斷標準很簡單拼接次數(shù)少、內(nèi)容固定用在循環(huán)里拼、拼的量級大用StringBuilder。另外StringBuilder不是線程安全的多線程追加要注意同步。3.4 Substring會復制截取子串前先想清楚Substring是另一個高頻操作。很多人誤以為Substring只是“切一個視圖”成本很低實際上它每次都會復制出新的字符串對象。當你只需要讀一下子串內(nèi)容卻不斷調(diào)用Substring時比如解析大文本、CSV、JSON會產(chǎn)生大量臨時字符串。這時候應該用AsSpan避免分配ReadOnlySpanchar span text.AsSpan(start, length); // 直接使用 span 做解析、比較零分配Span是視圖不復制字符數(shù)據(jù)處理完就沒了。這個特性從.NET Core 2.1開始可用對解析類代碼優(yōu)化顯著。但有一點要清楚如果截出來必須是一個獨立的string比如作為字典key、放進列表那就只能接受Substring的復制成本。這是不可變現(xiàn)出來的必然結(jié)果——你不能把一個“視圖”長期保存因為原始字符串可能已經(jīng)被回收了。做性能優(yōu)化時先問自己我要的是字符串本身還是只是暫時看一眼4. 實操過程一條完整的編碼鏈路以及我踩過的三個坑4.1 從文件讀取BOM、默認編碼和GBK老文件先說我處理過的一個真實案例。客戶給了一個CSVExcel導出的里面全是中文。我在.NET 6下直接File.ReadAllText(path)讀出來全是亂碼。查下來原因是文件沒有BOM編碼是GBK而File.ReadAllText在無BOM時默認按UTF-8解碼——GBK和UTF-8對中文的字節(jié)布局完全不一樣自然全亂。解決辦法是顯式指定編碼Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); string content File.ReadAllText(path, Encoding.GetEncoding(GB18030));GB18030幾乎兼容所有GBK/GB2312字符比用936更穩(wěn)妥。如果是自己程序?qū)懭罩?、配置文件我強烈建議統(tǒng)一UTF-8并讓寫入端顯式指定編碼。讀文件前先看BOM有BOM的優(yōu)先讓系統(tǒng)自動檢測無BOM的最好通過配置或約定告訴讀取端到底是什么編碼。4.2 從網(wǎng)絡和數(shù)據(jù)庫接收字符串charset和連接串都有坑網(wǎng)絡傳輸中最常見的亂碼原因是響應頭聲明的charset和實際編碼不一致。比如后端返回GBK數(shù)據(jù)Content-Type寫utf-8前端把字節(jié)按UTF-8解必亂。.NET里用HttpClient拿響應內(nèi)容時如果響應頭沒有明確charset很多實現(xiàn)會按一層默認編碼解讀遇到GBK接口就得手動處理byte[] raw await response.Content.ReadAsByteArrayAsync(); string text Encoding.GetEncoding(GB18030).GetString(raw);這是調(diào)老系統(tǒng)接口時經(jīng)常用到的兜底寫法。數(shù)據(jù)庫同理。SQL Server的NVarChar/NText是UTF-16MySQL的utf8mb4是UTF-8連接字符串里的Charset參數(shù)要和表結(jié)構(gòu)、客戶端三方對齊。MySQL傳回來亂碼的案例我見過十次有八次是連接串漏了charsetutf8mb4或者表本身是latin1。4.3 控制臺、日志和編碼驗證控制臺亂碼也高頻尤其是Windows。C#控制臺輸出中文變成問號多半是控制臺代碼頁不匹配。代碼里設置一下Console.OutputEncoding Encoding.UTF8;日志輸出建議統(tǒng)一UTF-8跨平臺、跨工具都穩(wěn)定。同一套日志W(wǎng)indows記事本按ANSI打開是GBK在Linux按UTF-8打開是亂碼這類問題都是“沒有顯式統(tǒng)一編碼”造成的。最后給一個自檢用的最小閉環(huán)驗證你的編碼鏈路是否通暢string original 你好世界; byte[] utf8 Encoding.UTF8.GetBytes(original); string back Encoding.UTF8.GetString(utf8); Console.WriteLine(original back); // True把“寫入編碼”和“讀出編碼”固定下來整個鏈路就穩(wěn)了。記住ASCII之外的文本絕不要用系統(tǒng)默認編碼做存儲或傳輸默認值在不同環(huán)境可能完全不同。5. 常見亂碼問題與面試高頻點速查5.1 中文亂碼的三種特征與排查套路亂碼不是玄學它是字節(jié)序列被錯誤解釋的必然結(jié)果。看到“錕斤拷”通常是UTF-8的內(nèi)容先用GBK解碼再把得到的字符重新編碼成UTF-8中間的替換符被GBK顯示成了“錕斤拷”。看到“????”多半是目標編碼字符集沒有這個字符直接拿問號替代?？吹揭淮盃C燙燙”那是沒初始化內(nèi)存的調(diào)試填充值不是編碼問題。排查順序記住這幾步先拿到原始字節(jié)別在已經(jīng)變成字符串的亂碼上猜看有沒有BOM有BOM基本能鎖定無BOM就根據(jù)來源判斷編碼一般老系統(tǒng)是GBK/GB2312現(xiàn)代接口默認UTF-8用對應編碼GetString如果對問題就出在“拿到的字符串已經(jīng)在某個環(huán)節(jié)被錯誤解碼過”。我經(jīng)常跟團隊說的一句話編碼問題要在字節(jié)層面解決不要在字符層面瞎猜。一旦字符串在錯誤編碼下被解碼過一次再轉(zhuǎn)回原編碼就困難了因為信息已經(jīng)丟了。所以寫代碼時傳輸、存儲、讀取三個環(huán)節(jié)的編碼必須顯式、統(tǒng)一、可配置。5.2 字符串比較、Equals、ReferenceEquals到底怎么選string是引用類型但被重載成了按值比較所以abc abc為true。Equals也按值比較。真正判斷“是不是同一個對象”要用ReferenceEquals。駐留機制經(jīng)常讓人懵字面量相等的字符串ReferenceEquals也經(jīng)常為true會給初學者造成“是引用比較”的錯覺。實際開發(fā)里比較內(nèi)容就用或string.Equals比較性能要求高時可以顯式傳StringComparison。大小寫不敏感用StringComparison.OrdinalIgnoreCase它比CurrentCultureIgnoreCase更可控。注意culture相關(guān)的比較有時會讓你大跌眼鏡比如土耳其語環(huán)境下i.ToUpper()不是I而是帶點的?。國際化應用里比較字符串盡量用ordinal而非culture除非你確實需要本地化排序。5.3 面試高頻題速查不可變、存儲和編碼一次講清面試問題一句話回答string是值類型還是引用類型引用類型但被重載為按內(nèi)容比較string為什么要不可變線程安全、哈希緩存安全、引用可放心共享為什么StringBuilder比循環(huán)高效拼接會創(chuàng)建大量不可變臨時對象StringBuilder在緩沖區(qū)上追加字符串駐留是什么相同內(nèi)容的字面量在CLR駐留池中復用同一實例s.Length是字符數(shù)嗎是UTF-16代碼單元數(shù)不是用戶可見字符數(shù)不是字節(jié)數(shù)中文亂碼的本質(zhì)寫入和讀取用了不同的字符編碼.NET里能用GBK嗎.NET Core需要Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)如果面試官再往深問可以補一句Java的String同樣不可變Java 9以后內(nèi)部用byte[]加coder做緊湊存儲.NET則是char數(shù)據(jù)內(nèi)聯(lián)在對象里。至于Java的StringBuffer那是在Java里用于線程安全字符串拼接的類.NET里并沒有StringBuffer對應角色是StringBuilder很多從Java轉(zhuǎn)C#的同事會混淆面試卡在這一下就能暴露基礎。6. 最后幾條我用真金白銀換來的String使用心法紙上談兵容易踩過坑才算數(shù)。我這些年調(diào)過最多的字符串問題不是性能而是編碼。所以我的第一條心法是凡是讀寫文件、發(fā)HTTP請求、連數(shù)據(jù)庫編碼一定要顯式寫死絕不依賴環(huán)境默認值。團隊代碼規(guī)范里如果有這一條能擋掉一半以上的亂碼工單。第二條不可變是保護不是限制。不要為了省內(nèi)存去Intern用戶輸入也不要在循環(huán)里用拼大字符串。真到需要極致性能時用Span、用StringBuilder、用Rune但先搞清楚自己的瓶頸到底在不在字符串上。很多時候真正拖垮系統(tǒng)的不是字符串本身而是到處復制的中間結(jié)果。第三條小技巧如果需要對大量重復字符串做去重和復用我更傾向用Dictionarystring, string做顯式緩存而不是string.Intern。字典緩存可控、可清、可統(tǒng)計命中和容量駐留池則是一條路走到黑。這個差異在長期運行的服務里非常明顯。