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