1. 為什么要把 string 的基礎(chǔ)重新捋一遍做 C 開發(fā)越久越會發(fā)現(xiàn)真正讓大家在項目里翻車的往往不是那些花哨的模板元編程反而是每天都寫在代碼里的std::string。這個類型太常用了常到很多人寫的時候根本不經(jīng)過大腦等到線上程序出現(xiàn)內(nèi)存越界、數(shù)據(jù)被莫名篡改、性能突然劣化回頭排查才發(fā)現(xiàn)是最基礎(chǔ)的字符串操作沒整明白。string類本質(zhì)上是一個管理字符序列的容器它把const char*那套手工管理內(nèi)存的方式封裝了起來自動處理申請、釋放、拷貝和擴容。聽起來很美好但封裝也意味著隱藏了不少細節(jié)size()和capacity()不是一回事operator[]和at()的越界行為完全不同reserve()用不好反而浪費內(nèi)存c_str()返回的指針有時效性substr()看起來輕巧實則可能做了一次全量拷貝。這些東西教科書里都提過但很多資料只是羅列接口不講使用場景和真實后果。這篇文章從實戰(zhàn)角度把這些基礎(chǔ)知識點串起來適合剛接觸 C 的同學(xué)系統(tǒng)過一遍也適合寫了兩三年程序但是從來沒深究過string內(nèi)部行為的開發(fā)者查漏補缺。我不會把文檔抄一遍而是把平時最容易踩坑、最影響性能和正確性的地方攤開來說。1.1 從 C 字符串到 C string 的核心改版在老式 C 代碼里字符串實際上就是一個以\0結(jié)尾的字符數(shù)組。你要知道數(shù)組長度要小心緩沖區(qū)溢出要用strcpy、strcat、strcmp這些函數(shù)操作它。最麻煩的是內(nèi)存所有權(quán)問題誰負責(zé)free傳進去的是指針還是副本要不要留出終止符的位置string改掉了這套玩法。它自己管理內(nèi)存遇到拷貝構(gòu)造會生成一份獨立數(shù)據(jù)賦值時可以自動擴張內(nèi)部緩沖區(qū)比較直接用而不是strcmp拼接用或append而不用先算長度再手動拼接。對于開發(fā)者來說容錯性直線上升但這不代表可以完全放飛。比如說把一個string傳給 C 接口時取c_str()如果后續(xù)又調(diào)用了修改字符串的接口那之前拿到的指針就可能懸空。這類問題本質(zhì)上是基礎(chǔ)概念沒吃透不是接口不好用。1.2 一個 string 對象在內(nèi)存里大概長什么樣先建立一個直觀印象。一個string對象本身通常是一個結(jié)構(gòu)體里面至少包含幾個關(guān)鍵成員當(dāng)前字符串長度、已分配緩沖區(qū)容量、指向?qū)嶋H字符數(shù)據(jù)的指針。在比較新的標(biāo)準(zhǔn)庫實現(xiàn)里還會做小字符串優(yōu)化SSO也就是當(dāng)字符串很短時直接存在對象內(nèi)部的棧數(shù)組里不額外分配堆內(nèi)存。這意味著什么你在棧上定義std::string s hi;時大概率根本沒有觸發(fā)堆分配字符就放在對象內(nèi)部。而當(dāng)字符串超過某個閾值常見實現(xiàn)是 15 個字符左右它才轉(zhuǎn)到堆上存儲。這個機制解釋了為什么有些看起來一樣的代碼性能差異卻很明顯短字符串和長字符串走的完全是兩條路。理解了內(nèi)存布局許多 API 的行為就順理成章了?？截愐粋€短字符串是廉價內(nèi)存復(fù)制拷貝一個長字符串可能涉及堆分配和搬運capacity()比size()大是預(yù)留給未來的增長shrink_to_fit()是嘗試把多余容量還給系統(tǒng)但標(biāo)準(zhǔn)不保證一定成功。2. 構(gòu)造與初始化別小看那些括號和等號string的構(gòu)造函數(shù)有好多種寫法很多新手甚至部分老手都不清楚它們各自的語義差異。特別是初始化列表和賦值之間一個細微的區(qū)別就可能多出一次不必要的臨時對象構(gòu)造。2.1 最常見的幾種構(gòu)造寫法對照直接看代碼比較直觀#include string #include iostream int main() { std::string s0; // 空字符串 std::string s1(hello); // 從 const char* 構(gòu)造 std::string s2 hello; // 寫法不同本質(zhì)與上一行相同 std::string s3(5, a); // 5 個 a得到 aaaaa std::string s4(s1); // 拷貝構(gòu)造 std::string s5(s1, 1, 3); // 取 s1[1] 開始長度 3得到 ell std::string s6(s1.begin() 1, s1.end()); // 用迭代器范圍構(gòu)造 std::cout s0.size() s1 s3 \n; std::cout s5 s6 \n; return 0; }std::string s2 hello;和std::string s1(hello);在 C11 之后語義基本一致不會因為你寫了等號就多一次拷貝。真正需要注意的反而是另一種寫法std::string s7 s1 world; // 右側(cè)先生成臨時 string再拷貝給 s7 std::string s8(s1 world); // 直接以臨時對象構(gòu)造 s8理論上第二種寫法有機會省掉一次拷貝。現(xiàn)代編譯器的優(yōu)化能力很強這兩種寫法在多數(shù)情況下生成的指令差別不大但在性能敏感代碼里養(yǎng)成直接構(gòu)造的習(xí)慣沒有壞處。2.2 隱式轉(zhuǎn)換、臨時對象與只讀場景的注意點string可以從const char*隱式構(gòu)造。這在傳參時很方便但也帶來一個隱蔽的問題如果函數(shù)形參是std::string你傳入一個字面量每次調(diào)用都會創(chuàng)建一個新的string對象。如果這個函數(shù)只讀不寫更好的選擇是接收std::string_view或const std::string。我見過不少同事寫接口時直接void process(const std::string s)這個形參會觸發(fā)一次拷貝。改成const std::string可以避免拷貝再進一步如果函數(shù)只需要讀取字符不調(diào)用任何string的復(fù)雜操作std::string_view是更輕量的選擇。當(dāng)然這是題外話但理解string的構(gòu)造成本自然會引導(dǎo)你往這些方向思考。還有一類問題是把比較特殊的值傳給構(gòu)造函數(shù)。比如把nullptr直接丟給string構(gòu)造函數(shù)這是典型的未定義行為大多數(shù)編譯器在運行時直接崩潰或產(chǎn)生不可預(yù)測結(jié)果。正確做法是先判斷指針是否為空再構(gòu)造。在代碼審查里看到有人寫std::string str(ptr);而ptr可能為空時我都會要求先加判空。2.3 用字符數(shù)組、string_view 與 string 交互的邊界字符數(shù)組轉(zhuǎn)string時要小心數(shù)組是否以\0結(jié)尾。構(gòu)造函數(shù)依賴終止符來確認字符串長度如果傳入的數(shù)組沒有終止符它會一直讀下去直到撞上內(nèi)存里的某個\0輕則生成錯誤內(nèi)容重則越界訪問。安全起見可以用帶長度的構(gòu)造方式例如char buf[4] {a, b, c, d}; std::string s(buf, 4); // 明確傳入長度不依賴終止符從 C17 開始越來越推薦在只讀場景使用std::string_view。它可以指向string的內(nèi)部數(shù)據(jù)也可以指向一個字符數(shù)組或字面量構(gòu)造不需要復(fù)制字符。但要注意string_view不擁有數(shù)據(jù)它只是視圖。底層字符串如果被修改或銷毀string_view就會失效。把string_view轉(zhuǎn)換成string是隨手為之的事反過來則要慎重考慮生命周期。3. 容量操作size、capacity、reserve、resize 背后的邏輯容量相關(guān)的成員函數(shù)看上去很簡單實際是string性能問題的根源。很多人寫字符串拼接時從不預(yù)留空間導(dǎo)致字符串在循環(huán)里反復(fù)擴容、反復(fù)搬運數(shù)據(jù)性能慘不忍睹。3.1 size、length、capacity 三者到底差在哪里size()和length()完全等價返回的都是字符串當(dāng)前有效字符個數(shù)不包含末尾的\0。std::string s abc; s.size()的結(jié)果是 3不是 4。capacity()返回的是在不重新分配內(nèi)存的前提下字符串最多還能存多少個字符。注意它和size()是兩個維度size是已經(jīng)用掉的空間capacity是手上擁有的空間。那\0呢很多人會把size()和strlen()混淆。strlen(abc)返回 3std::string(abc).size()也返回 3看起來一樣但string內(nèi)部可以存儲\0字符size()會如實統(tǒng)計而strlen遇到第一個\0就停了。舉個例子std::string s abc; s.push_back(\0); s.append(def); std::cout s.size() \n; // 輸出 7 std::cout strlen(s.c_str()) \n; // 輸出 3因為 c_str() 在 \0 處截斷這個區(qū)別在實際開發(fā)中經(jīng)常引發(fā)詭異 bug尤其是接底層 C 接口時。判斷字符串是否為空只應(yīng)該用empty()不要用size() 0的寫法——雖然邏輯等價但empty()語義更清晰而且某些實現(xiàn)里empty()是常數(shù)時間檢查。3.2 reserve 為什么是性能優(yōu)化第一步string在追加字符時如果當(dāng)前capacity()不夠會重新申請更大的內(nèi)存把舊數(shù)據(jù)搬過去再釋放舊內(nèi)存。這種重分配通常按倍數(shù)增長常見實現(xiàn)是 2 倍左右。單次重分配可能不覺得慢但在循環(huán)里逐字符拼接時性能損失會被放大。解決方案很簡單提前reserve()。如果你能估算出最終長度的上界一上來就把容量預(yù)留夠后續(xù)拼接只是簡單地寫數(shù)據(jù)完美避開重分配。std::string result; result.reserve(10000); for (int i 0; i 10000; i) { result x; }我實測過一個場景生成一個幾 MB 的日志字符串不reserve時重分配次數(shù)高達幾十次累計耗時明顯reserve之后整個過程幾乎無感知。這里有個細節(jié)reserve(n)只是建議預(yù)留至少n個字符的空間實際capacity()可能比n更大這是完全正常的行為。還有一個容易被忽略的點reserve之后使用迭代器、指針或引用時這些訪問器可能會因為未來的重分配而失效。即便你已經(jīng)reserve夠了只要后續(xù)操作沒有觸發(fā)重分配它們依然有效一旦某些操作還是觸發(fā)了重分配舊訪問器就全部作廢。3.3 resize 與字符填充的坑resize(n)會把字符串長度調(diào)整為n。如果n大于當(dāng)前長度多出來的部分會用\0填充或指定的字符如果n小于當(dāng)前長度尾部字符會被丟棄。它和reserve(n)最大的區(qū)別是resize真的改變size()而reserve只改變capacity()。有人想在循環(huán)里用resize預(yù)留空間結(jié)果發(fā)現(xiàn)字符串變量莫名多了一堆\0字符就是因為這兩個名字太像、行為完全不同。std::string s hello; s.resize(10); // s 變成 hello\0\0\0\0\0 s.reserve(20); // s 仍然是 hello\0\0\0\0\0 s.resize(3); // s 變成 hel\0字符在控制臺輸出時不可見非常容易誤判。如果你只是想給后續(xù)寫入留位置正確姿勢是用resize搭配data()寫入后手動調(diào)整resize或者直接用reserve配合append。3.4 empty、clear 和 shrink_to_fit 的適用時機clear()將字符串長度置零但capacity()通常保持不變。也就是說執(zhí)行clear()后再empty()返回true但底層那塊內(nèi)存還在還可以繼續(xù)復(fù)用這本身是好事尤其適合循環(huán)復(fù)用同一個string對象的場景。shrink_to_fit()和clear()配合會產(chǎn)生一個微妙效果先clear()再shrink_to_fit()可以把容量也壓縮下去但這是一次 O(n) 的重分配操作。如果只是短時間想清空字符串別頻繁調(diào)用shrink_to_fit()否則得不償失。我的習(xí)慣是復(fù)用同一個字符串來拼接日志時用clear()內(nèi)存吃緊且字符串長期存活時才考慮shrink_to_fit()。4. 元素訪問和修改[]、at()、append、insert、erase、replace 的取舍訪問單個字符和修改字符串內(nèi)容是日常使用頻率最高的操作。這些接口各有邊界條件選錯了很容易埋下隱患。4.1 operator[] 和 at()一個為速度一個為安全operator[]不檢查越界。訪問越界位置屬于未定義行為也許讀取到垃圾數(shù)據(jù)也許直接段錯誤。at()在越界時會拋出std::out_of_range異常。std::string s abc; char c1 s[10]; // 未定義行為僥幸可能返回垃圾值 char c2 s.at(10); // 拋出 std::out_of_range性能上operator[]沒有分支判斷內(nèi)聯(lián)后幾乎就是一次指針運算at()帶檢查會多一些開銷。絕大多數(shù)只需要從 0 到size()-1的正常遍歷直接用索引或范圍 for 循環(huán)就行。不要為了那一點點異常安全把每個讀取都換成at()異常拋出不是用來給正常流程兜底的。但有一個場景我強烈建議用at()在你自己都拿不準(zhǔn)下標(biāo)是否合法的解析代碼里。比如處理網(wǎng)絡(luò)協(xié)議頭時緩沖區(qū)長度來自遠端一旦解析出錯與其讀到越界內(nèi)存不如讓它拋異常然后統(tǒng)一捕獲處理。這種情況下性能換來的確定性是非常值得的。4.2 追加、插入、刪除、替換怎么選追加字符優(yōu)先push_back()追加字符串用append()或。append可以指定追加范圍比如append(s, pos, count)比手動substr再拼接高效得多。插入用insert()傳入迭代器位置或下標(biāo)功能很強但很容易犯糊涂因為它有大量重載。刪除用erase()按下標(biāo)范圍或迭代器范圍刪除。真正容易被忽略的是replace()。很多人想替換一段子串時習(xí)慣先erase再insert兩步操作有兩個問題一是臨時改變了字符串長度和內(nèi)容如果中間拋出異常或提前 return狀態(tài)會不一致二是多次操作可能引發(fā)多次容量調(diào)整。replace()一步到位語義也清晰。std::string s hello world; s.replace(6, 5, C); // 從位置 6 開始刪掉 5 個字符換成 C // s 變成 hello C用replace時要注意第一個參數(shù)是起始下標(biāo)第二個參數(shù)是“要刪除的字符數(shù)”不是目標(biāo)字符串長度。這個參數(shù)傳錯是常見錯誤來源。4.3 swap 和移動語義在拼接場景的作用拼接大量字符串時除了reserve另一個提升效率的手段是善用移動語義和swap。std::string build(const std::vectorstd::string parts) { std::string result; for (const auto part : parts) { result part; } return result; }如果傳入的parts中有些元素是臨時構(gòu)造的用result std::move(part)可以把字符數(shù)據(jù)轉(zhuǎn)移過來而不必復(fù)制前提是函數(shù)明確不再需要part的原有內(nèi)容。swap在需要快速交換兩個字符串內(nèi)容時特別有用。a.swap(b)基本上只交換內(nèi)部指針和大小成員不碰字符數(shù)據(jù)本身哪怕兩個字符串都很長也是常數(shù)級開銷。比手動std::string tmp a; a b; b tmp;不止快了一個量級。5. 查找與截取find 系列、rfind 和 substr 的細節(jié)查找函數(shù)是string里最能迷惑人的部分因為find的家族成員實在太多了而且每個的語義都不太一樣。搞混它們最常見的后果是寫出的代碼“偶爾能跑、大多數(shù)時候偏偏返回錯誤結(jié)果”。5.1 find 與 rfind 的查找方向find從前往后找返回第一個匹配子串的位置rfind從后往前找返回最后一個匹配子串的位置。兩者都不是“找一個然后停止”而是根據(jù)方向找第一個命中的位置。std::string s banana; std::cout s.find(a) \n; // 1 std::cout s.rfind(a) \n; // 5如果找不到返回std::string::npos。這是一個很大的size_t值比較時大概率沒事但要注意不要順手把它轉(zhuǎn)成int否則數(shù)值會變成 -1后續(xù)判斷全亂。有個細節(jié)find支持指定起始位置s.find(ch, pos)從pos開始查找。rfind 的第二個參數(shù)含義則讓人犯迷糊——它表示的是“從這個位置開始往前找”不是“找完前 n 個位置”。想找最后一段分隔符后面的內(nèi)容很多人會寫s.rfind(/, s.size() - 1)其實s.rfind(/)本身就是從末尾開始再加這個參數(shù)反而容易算錯。5.2 find_first_of 與 find_first_not_of 的使用場景find_first_of和find名字像行為差很多。find(abc)找的是子串a(chǎn)bc整體出現(xiàn)的位置find_first_of(abc)找的是字符a、b、c中任意一個最早出現(xiàn)的位置。std::string s hello world; s.find_first_of(aeiou); // 找第一個元音結(jié)果是 1e 的位置 s.find_last_of(aeiou); // 找最后一個元音結(jié)果是 7o 的位置 s.find_first_not_of(helo ); // 找第一個不屬于這些字符的位置這類函數(shù)在做字符分類時非常順滑比如解析一行文本、剝離空白、按分隔符掃描。與正則表達式相比它們是線性查找沒有額外開銷適合輕量解析。唯一要留意的是參數(shù)含義是“字符集合”不是“子串”寫錯會得到完全不同的結(jié)果。5.3 substr 的邊界、異常和拷貝成本substr(pos, count)從pos開始截取count個字符。如果pos越界拋std::out_of_range如果count超過剩余長度就取到字符串末尾為止不會報錯。很多教程把它描繪成“輕量操作”這是一種誤導(dǎo)。substr()返回的是新構(gòu)造的string內(nèi)部字符數(shù)據(jù)會被完整復(fù)制。大字符串頻繁substr會產(chǎn)生可觀的拷貝成本和時間開銷尤其在一個循環(huán)里反復(fù)截取時?，F(xiàn)代 C 里如果只是想“看一眼”某個子串而不需要長期持有優(yōu)先用std::string_viewstd::string_view sv(s); std::string_view part sv.substr(0, 5); // 只記錄起始位置和長度不復(fù)制字符需要生成獨立字符串時才用substr()。我處理日志文件時經(jīng)常遇到大字符串反復(fù)截取造成內(nèi)存暴漲的情況換成string_view后內(nèi)存占用直接降下來。6. 轉(zhuǎn)換與 C 接口交互數(shù)字解析、c_str() 和 stringstreamstring很少獨立存在它常常要跟數(shù)字互相轉(zhuǎn)換、跟 C 接口交換數(shù)據(jù)。這些轉(zhuǎn)換操作里藏著不少版本和生命周期陷阱。6.1 數(shù)字轉(zhuǎn)字符串的三種主流寫法C11 之前大家常用sprintf或stringstream來格式化數(shù)字。C11 引入了std::to_string把整數(shù)和浮點數(shù)轉(zhuǎn)成字符串變得一行搞定std::string s1 std::to_string(42); std::string s2 std::to_string(3.14159);to_string底層用printf家族實現(xiàn)轉(zhuǎn)換浮點數(shù)時默認精度是 6 位。如果對格式有要求比如保留兩位小數(shù)、補零、科學(xué)計數(shù)法to_string就不夠用了。這時候兩種處理方案一種是繼續(xù)用stringstream配合std::fixed、std::setprecision控制輸出格式缺點是寫法略啰嗦但可讀性和靈活性都很好。另一種是直接用 C 的snprintf生成到臨時字符數(shù)組再轉(zhuǎn)成string。效率往往比stringstream高格式控制又比to_string靈活是很多性能敏感模塊的選擇。注意緩沖區(qū)長度要留夠養(yǎng)成傳入sizeof(buf)的習(xí)慣。6.2 字符串轉(zhuǎn)數(shù)字的解析細節(jié)C11 提供了stoi、stol、stoll、stof、stod、stold這些解析函數(shù)。它們都可以指定起始位置和進制但實際開發(fā)中容易忽視兩個異常解析失敗時拋std::invalid_argument數(shù)值超出范圍時拋std::out_of_range。std::string s 123abc; size_t pos 0; int value std::stoi(s, pos); // value 是 123pos 指向 3a 之前的位置如果字符串中間混有非數(shù)字字符stoi會盡量解析前面的數(shù)字部分并把pos更新到停止位置。用這個特性可以做簡單的前綴解析。但要小心空字符串、全非數(shù)字字符串、開頭就有空格的情況它們的行為各不相同建議在解析前先自行判斷。std::stringstream的解析容忍度更高比如ss number時會跳過前導(dǎo)空白遇到非數(shù)字字符時停止。具體用哪個取決于你期望多嚴(yán)格。一個常見的錯誤是拿到用戶輸入后直接stoi沒做任何格式校驗結(jié)果一行惡意輸入字段就把進程帶崩。正確的做法是先判斷內(nèi)容是否符合預(yù)期格式再轉(zhuǎn)數(shù)字。涉及進制時要注意stoi(s, nullptr, 16)第三個參數(shù)指定進制但字符串前綴0x的處理在不同編譯器實現(xiàn)下略有差異。不要依賴“自動識別前綴”這種能力盡量顯式指定進制。6.3 c_str() 返回的指針什么時候會失效c_str()返回一個指向string內(nèi)部字符緩沖區(qū)的const char*它一定以\0結(jié)尾。但這個指針不是永久有效的只要后續(xù)對字符串執(zhí)行了任何可能導(dǎo)致緩沖區(qū)重分配的操作比如追加字符超過容量、調(diào)用resize、append、push_back甚至調(diào)用非常量版本的operator[]都可能讓已取得的指針失效。const char* p s.c_str(); s extra; // 可能重分配內(nèi)存p 變成懸空指針 printf(%s, p); // 危險還有一個常見失誤把c_str()的結(jié)果存下來放到容器里等字符串銷毀后再去用。這個指針指向的對象已經(jīng)不存在訪問它屬于未定義行為。反過來看如果只是讀操作c_str()拿到的是穩(wěn)定視圖。一個值得養(yǎng)成的習(xí)慣是需要長期保存字符串內(nèi)容時直接拷貝一份string而不是保存c_str()的指針。很多接口設(shè)計上的詭異崩潰追根溯源都是這種“保存了不該保存的指針”。data()的語義在 C11 之前和c_str()不同但 C11 之后兩者都保證以\0結(jié)尾可以認為等價。C17 起data()對非常量版本返回char*可以直接用來寫入。寫入時務(wù)必確保下標(biāo)不越界否則又回到未定義行為的坑里。7. 這些年在 string 上看到的典型問題前面按接口過了一遍這里集中記錄幾個我在代碼審查和實際排障里反復(fù)見到的問題每一條幾乎都是線上真實發(fā)生過的。7.1 沒給拼接留空間反而頻繁重分配一個非常典型的場景是循環(huán)構(gòu)造 SQL 或日志文本std::string query; for (auto row : rows) { query row.name; query ,; }幾千行數(shù)據(jù)拼接時query內(nèi)部會反復(fù)擴容。大多數(shù)實現(xiàn)為了攤還成本會按倍數(shù)增長所以問題不至于失控但在字符串特別長、循環(huán)特別多、調(diào)用特別頻繁的代碼路徑上重分配次數(shù)會到幾十上百次。肉眼可見的現(xiàn)象是capacity()忽大忽小分配器頻繁調(diào)用整體耗時上不去。修復(fù)方式很簡單循環(huán)前估算總量并reserve()。如果實在估不準(zhǔn)可以先按一個較合理的初值預(yù)留比如query.reserve(1024)讓它至少度過前幾輪小規(guī)模增長。順帶一提有人會在循環(huán)里寫query.clear()后繼續(xù)追加這個模式并沒有問題但如果用的是std::string query;每次循環(huán)新建分配成本就完全不一樣了。復(fù)用對象是減少分配的最直接手段。7.2 迭代器、引用和指針的失效問題重分配是各種“神秘 bug”的源頭。保存了指向string內(nèi)部字符的指針或迭代器然后繼續(xù)往字符串里追加內(nèi)容后續(xù)訪問時就可能讀到舊地址上的垃圾數(shù)據(jù)。這種問題不穩(wěn)定復(fù)現(xiàn)因為小字符串走 SSO、大字符串走堆分配觸發(fā)條件很隨機。我有一次排一個詭異的內(nèi)存崩潰崩潰點在一個看似安全的strcmp上。排查到最后發(fā)現(xiàn)開發(fā)者先前把s.c_str()存進了全局變量后續(xù)另一個線程往同一個string上追加日志把底層指針換了全局變量成了野指針。這提醒我一條規(guī)則不要長期持有string內(nèi)部數(shù)據(jù)的任何訪問器除非你能確保期間沒有非 const 操作。7.3 比較排序時忽略大小寫和區(qū)域設(shè)置std::string的、、compare()都是按字符的底層編碼值逐字節(jié)比較的不做大小寫歸一化。對 ASCII 字符來說A 小于 a對包含中文等非 ASCII 字符的 UTF-8 字符串直接比較得到的順序和“字典序”往往對不上。需要忽略大小寫時要手動轉(zhuǎn)換后再比比如std::tolower逐字符處理或者用cctype里的函數(shù)做比較器。比較麻煩的是 Unicode 字符std::tolower只處理單字節(jié)字符不能直接處理 UTF-8 多字節(jié)序列。真要按人類語言習(xí)慣排序需要引入 ICU 這類庫或者自定義比較函數(shù)。另一個常被忽視的點是compare()的返回值小于 0、等于 0、大于 0而不是簡單的true/false。寫成if (s.compare(t) 0)是對的寫成if (s.compare(t))就弄反了。7.4 版本差異C11 前后的行為變化很多項目至今還在用 C98/03 風(fēng)格的寫法碰到string的一些行為差異會踩坑。比如 C11 之后data()和c_str()行為等價C11 之前data()不保證以\0結(jié)尾老代碼把data()當(dāng)c_str()用就會導(dǎo)致越界讀取。std::string的拷貝語義在引入移動語義后也變了按值返回大字符串時可以依靠移動或者編譯器的返回值優(yōu)化甩掉一次拷貝而在老標(biāo)準(zhǔn)里無論如何都會拷一份。如果你的代碼既有老分支又有新分支這種差異會導(dǎo)致同一個函數(shù)在兩邊性能表現(xiàn)完全不同。還有一個小坑是std::string和字符串字面量直接拼接時的重載解析。C11 之后寫s abc和abc s都合法字面量會隱式轉(zhuǎn)成string。但如果兩個操作數(shù)都是const char*編譯器沒有可用于拼接的運算符這也是新手常犯的編譯錯誤。8. 最后補一句我的使用心得最近兩年我審查過的代碼里字符串相關(guān)的 bug 占比一直不低但絕大多數(shù)只要把size和capacity、find和find_first_of、substr和string_view這幾組概念掰開來看問題很快就能定位。我自己寫字符串密集的代碼時養(yǎng)成了一套固定習(xí)慣能預(yù)估長度就reserve能傳引用就傳引用能只讀就用string_view能不持有c_str()返回的指針就不持有循環(huán)里盡量復(fù)用一個局部string而不是反復(fù)構(gòu)造新對象。這些習(xí)慣不用刻意背誦寫久了自然熟練。最后再分享一個小技巧在編譯器開啟-Wall和-Wextra很多字符串相關(guān)的越界和類型轉(zhuǎn)換問題會提前暴露。如果不確定某個 API 的邊界行為寫十行測試代碼跑一下比翻半天文檔更直接。string這門基礎(chǔ)課值得花一兩個晚上徹底弄清楚回報率比追那些花哨的新特性高多了。