1. 为什么要把 string 的基础重新捋一遍
做 C++ 开发越久越会发现，真正让大家在项目里翻车的，往往不是那些花哨的模板元编程，反而是每天都写在代码里的std::string。这个类型太常用了，常到很多人写的时候根本不经过大脑，等到线上程序出现内存越界、数据被莫名篡改、性能突然劣化，回头排查才发现是最基础的字符串操作没整明白。
string类本质上是一个管理字符序列的容器，它把const char*那套手工管理内存的方式封装了起来，自动处理申请、释放、拷贝和扩容。听起来很美好，但封装也意味着隐藏了不少细节：size()和capacity()不是一回事，operator[]和at()的越界行为完全不同，reserve()用不好反而浪费内存，c_str()返回的指针有时效性，substr()看起来轻巧实则可能做了一次全量拷贝。
这些东西教科书里都提过，但很多资料只是罗列接口，不讲使用场景和真实后果。这篇文章从实战角度把这些基础知识点串起来，适合刚接触 C++ 的同学系统过一遍，也适合写了两三年程序但是从来没深究过string内部行为的开发者查漏补缺。我不会把文档抄一遍，而是把平时最容易踩坑、最影响性能和正确性的地方摊开来说。
1.1 从 C 字符串到 C++ string 的核心改版
在老式 C 代码里，字符串实际上就是一个以\0结尾的字符数组。你要知道数组长度，要小心缓冲区溢出，要用strcpy、strcat、strcmp这些函数操作它。最麻烦的是内存所有权问题：谁负责free？传进去的是指针还是副本？要不要留出终止符的位置？
string改掉了这套玩法。它自己管理内存，遇到拷贝构造会生成一份独立数据，赋值时可以自动扩张内部缓冲区，比较直接用==而不是strcmp，拼接用+或append而不用先算长度再手动拼接。对于开发者来说，容错性直线上升，但这不代表可以完全放飞。比如说把一个string传给 C 接口时取c_str()，如果后续又调用了修改字符串的接口，那之前拿到的指针就可能悬空。这类问题本质上是基础概念没吃透，不是接口不好用。
1.2 一个 string 对象在内存里大概长什么样
先建立一个直观印象。一个string对象本身通常是一个结构体，里面至少包含几个关键成员：当前字符串长度、已分配缓冲区容量、指向实际字符数据的指针。在比较新的标准库实现里，还会做小字符串优化（SSO），也就是当字符串很短时直接存在对象内部的栈数组里，不额外分配堆内存。
这意味着什么？你在栈上定义std::string s = "hi";时，大概率根本没有触发堆分配，字符就放在对象内部。而当字符串超过某个阈值（常见实现是 15 个字符左右），它才转到堆上存储。这个机制解释了为什么有些看起来一样的代码，性能差异却很明显：短字符串和长字符串走的完全是两条路。
理解了内存布局，许多 API 的行为就顺理成章了。拷贝一个短字符串是廉价内存复制，拷贝一个长字符串可能涉及堆分配和搬运；capacity()比size()大是预留给未来的增长；shrink_to_fit()是尝试把多余容量还给系统，但标准不保证一定成功。
2. 构造与初始化：别小看那些括号和等号
string的构造函数有好多种写法，很多新手甚至部分老手都不清楚它们各自的语义差异。特别是初始化列表和赋值之间，一个细微的区别就可能多出一次不必要的临时对象构造。
2.1 最常见的几种构造写法对照
直接看代码比较直观：
#include <string> #include <iostream> int main() { std::string s0; // 空字符串 std::string s1("hello"); // 从 const char* 构造 std::string s2 = "hello"; // 写法不同，本质与上一行相同 std::string s3(5, 'a'); // 5 个 'a'，得到 "aaaaa" std::string s4(s1); // 拷贝构造 std::string s5(s1, 1, 3); // 取 s1[1] 开始长度 3，得到 "ell" std::string s6(s1.begin() + 1, s1.end()); // 用迭代器范围构造 std::cout << s0.size() << " " << s1 << " " << s3 << "\n"; std::cout << s5 << " " << s6 << "\n"; return 0; }std::string s2 = "hello";和std::string s1("hello");在 C++11 之后语义基本一致，不会因为你写了等号就多一次拷贝。真正需要注意的反而是另一种写法：
std::string s7 = s1 + " world"; // 右侧先生成临时 string，再拷贝给 s7 std::string s8(s1 + " world"); // 直接以临时对象构造 s8理论上第二种写法有机会省掉一次拷贝。现代编译器的优化能力很强，这两种写法在多数情况下生成的指令差别不大，但在性能敏感代码里，养成直接构造的习惯没有坏处。
2.2 隐式转换、临时对象与只读场景的注意点
string可以从const char*隐式构造。这在传参时很方便，但也带来一个隐蔽的问题：如果函数形参是std::string，你传入一个字面量，每次调用都会创建一个新的string对象。如果这个函数只读不写，更好的选择是接收std::string_view或const std::string&。
我见过不少同事写接口时直接void process(const std::string s)，这个形参会触发一次拷贝。改成const std::string&可以避免拷贝，再进一步，如果函数只需要读取字符，不调用任何string的复杂操作，std::string_view是更轻量的选择。当然这是题外话，但理解string的构造成本自然会引导你往这些方向思考。
还有一类问题是把比较特殊的值传给构造函数。比如把nullptr直接丢给string构造函数，这是典型的未定义行为，大多数编译器在运行时直接崩溃或产生不可预测结果。正确做法是先判断指针是否为空再构造。在代码审查里，看到有人写std::string str(ptr);而ptr可能为空时，我都会要求先加判空。
2.3 用字符数组、string_view 与 string 交互的边界
字符数组转string时要小心数组是否以\0结尾。构造函数依赖终止符来确认字符串长度，如果传入的数组没有终止符，它会一直读下去直到撞上内存里的某个\0，轻则生成错误内容，重则越界访问。安全起见，可以用带长度的构造方式，例如：
char buf[4] = {'a', 'b', 'c', 'd'}; std::string s(buf, 4); // 明确传入长度，不依赖终止符从 C++17 开始，越来越推荐在只读场景使用std::string_view。它可以指向string的内部数据，也可以指向一个字符数组或字面量，构造不需要复制字符。但要注意，string_view不拥有数据，它只是视图。底层字符串如果被修改或销毁，string_view就会失效。把string_view转换成string是随手为之的事，反过来则要慎重考虑生命周期。
3. 容量操作：size、capacity、reserve、resize 背后的逻辑
容量相关的成员函数看上去很简单，实际是string性能问题的根源。很多人写字符串拼接时从不预留空间，导致字符串在循环里反复扩容、反复搬运数据，性能惨不忍睹。
3.1 size、length、capacity 三者到底差在哪里
size()和length()完全等价，返回的都是字符串当前有效字符个数，不包含末尾的\0。std::string s = "abc"; s.size()的结果是 3，不是 4。
capacity()返回的是在不重新分配内存的前提下，字符串最多还能存多少个字符。注意它和size()是两个维度：size是已经用掉的空间，capacity是手上拥有的空间。
那\0呢？很多人会把size()和strlen()混淆。strlen("abc")返回 3，std::string("abc").size()也返回 3，看起来一样，但string内部可以存储\0字符，size()会如实统计；而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' 处截断这个区别在实际开发中经常引发诡异 bug，尤其是接底层 C 接口时。判断字符串是否为空只应该用empty()，不要用size() == 0的写法——虽然逻辑等价，但empty()语义更清晰，而且某些实现里empty()是常数时间检查。
3.2 reserve 为什么是性能优化第一步
string在追加字符时，如果当前capacity()不够，会重新申请更大的内存，把旧数据搬过去，再释放旧内存。这种重分配通常按倍数增长，常见实现是 2 倍左右。单次重分配可能不觉得慢，但在循环里逐字符拼接时，性能损失会被放大。
解决方案很简单：提前reserve()。如果你能估算出最终长度的上界，一上来就把容量预留够，后续拼接只是简单地写数据，完美避开重分配。
std::string result; result.reserve(10000); for (int i = 0; i < 10000; ++i) { result += "x"; }我实测过一个场景：生成一个几 MB 的日志字符串，不reserve时重分配次数高达几十次，累计耗时明显；reserve之后整个过程几乎无感知。这里有个细节，reserve(n)只是建议预留至少n个字符的空间，实际capacity()可能比n更大，这是完全正常的行为。
还有一个容易被忽略的点：reserve之后使用迭代器、指针或引用时，这些访问器可能会因为未来的重分配而失效。即便你已经reserve够了，只要后续操作没有触发重分配，它们依然有效；一旦某些操作还是触发了重分配，旧访问器就全部作废。
3.3 resize 与字符填充的坑
resize(n)会把字符串长度调整为n。如果n大于当前长度，多出来的部分会用\0填充（或指定的字符）；如果n小于当前长度，尾部字符会被丢弃。
它和reserve(n)最大的区别是：resize真的改变size()，而reserve只改变capacity()。有人想在循环里用resize预留空间，结果发现字符串变量莫名多了一堆\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字符在控制台输出时不可见，非常容易误判。如果你只是想给后续写入留位置，正确姿势是用resize搭配data()写入后手动调整resize，或者直接用reserve配合append。
3.4 empty、clear 和 shrink_to_fit 的适用时机
clear()将字符串长度置零，但capacity()通常保持不变。也就是说，执行clear()后再empty()返回true，但底层那块内存还在，还可以继续复用，这本身是好事，尤其适合循环复用同一个string对象的场景。
shrink_to_fit()和clear()配合会产生一个微妙效果：先clear()再shrink_to_fit()可以把容量也压缩下去，但这是一次 O(n) 的重分配操作。如果只是短时间想清空字符串，别频繁调用shrink_to_fit()，否则得不偿失。我的习惯是：复用同一个字符串来拼接日志时，用clear()；内存吃紧且字符串长期存活时，才考虑shrink_to_fit()。
4. 元素访问和修改：[]、at()、append、insert、erase、replace 的取舍
访问单个字符和修改字符串内容是日常使用频率最高的操作。这些接口各有边界条件，选错了很容易埋下隐患。
4.1 operator[] 和 at()：一个为速度，一个为安全
operator[]不检查越界。访问越界位置属于未定义行为，也许读取到垃圾数据，也许直接段错误。at()在越界时会抛出std::out_of_range异常。
std::string s = "abc"; char c1 = s[10]; // 未定义行为，侥幸可能返回垃圾值 char c2 = s.at(10); // 抛出 std::out_of_range性能上operator[]没有分支判断，内联后几乎就是一次指针运算；at()带检查，会多一些开销。绝大多数只需要从 0 到size()-1的正常遍历，直接用索引或范围 for 循环就行。不要为了那一点点异常安全把每个读取都换成at()，异常抛出不是用来给正常流程兜底的。
但有一个场景我强烈建议用at()：在你自己都拿不准下标是否合法的解析代码里。比如处理网络协议头时，缓冲区长度来自远端，一旦解析出错，与其读到越界内存，不如让它抛异常然后统一捕获处理。这种情况下，性能换来的确定性是非常值得的。
4.2 追加、插入、删除、替换怎么选
追加字符优先push_back()，追加字符串用append()或+=。append可以指定追加范围，比如append(s, pos, count)，比手动substr再拼接高效得多。
插入用insert()，传入迭代器位置或下标，功能很强但很容易犯糊涂，因为它有大量重载。删除用erase()，按下标范围或迭代器范围删除。
真正容易被忽略的是replace()。很多人想替换一段子串时，习惯先erase再insert，两步操作有两个问题：一是临时改变了字符串长度和内容，如果中间抛出异常或提前 return，状态会不一致；二是多次操作可能引发多次容量调整。replace()一步到位，语义也清晰。
std::string s = "hello world"; s.replace(6, 5, "C++"); // 从位置 6 开始删掉 5 个字符，换成 "C++" // s 变成 "hello C++"用replace时要注意第一个参数是起始下标，第二个参数是“要删除的字符数”，不是目标字符串长度。这个参数传错是常见错误来源。
4.3 swap 和移动语义在拼接场景的作用
拼接大量字符串时，除了reserve，另一个提升效率的手段是善用移动语义和swap。
std::string build(const std::vector<std::string>& parts) { std::string result; for (const auto& part : parts) { result += part; } return result; }如果传入的parts中有些元素是临时构造的，用result += std::move(part)可以把字符数据转移过来而不必复制，前提是函数明确不再需要part的原有内容。
swap在需要快速交换两个字符串内容时特别有用。a.swap(b)基本上只交换内部指针和大小成员，不碰字符数据本身，哪怕两个字符串都很长也是常数级开销。比手动std::string tmp = a; a = b; b = tmp;不止快了一个量级。
5. 查找与截取：find 系列、rfind 和 substr 的细节
查找函数是string里最能迷惑人的部分，因为find的家族成员实在太多了，而且每个的语义都不太一样。搞混它们最常见的后果是写出的代码“偶尔能跑、大多数时候偏偏返回错误结果”。
5.1 find 与 rfind 的查找方向
find从前往后找，返回第一个匹配子串的位置；rfind从后往前找，返回最后一个匹配子串的位置。两者都不是“找一个然后停止”，而是根据方向找第一个命中的位置。
std::string s = "banana"; std::cout << s.find("a") << "\n"; // 1 std::cout << s.rfind("a") << "\n"; // 5如果找不到，返回std::string::npos。这是一个很大的size_t值，比较时大概率没事，但要注意不要顺手把它转成int，否则数值会变成 -1，后续判断全乱。
有个细节：find支持指定起始位置，s.find(ch, pos)从pos开始查找。rfind 的第二个参数含义则让人犯迷糊——它表示的是“从这个位置开始往前找”，不是“找完前 n 个位置”。想找最后一段分隔符后面的内容，很多人会写s.rfind('/', s.size() - 1)，其实s.rfind('/')本身就是从末尾开始，再加这个参数反而容易算错。
5.2 find_first_of 与 find_first_not_of 的使用场景
find_first_of和find名字像，行为差很多。find("abc")找的是子串"abc"整体出现的位置；find_first_of("abc")找的是字符'a'、'b'、'c'中任意一个最早出现的位置。
std::string s = "hello world"; s.find_first_of("aeiou"); // 找第一个元音，结果是 1，'e' 的位置 s.find_last_of("aeiou"); // 找最后一个元音，结果是 7，'o' 的位置 s.find_first_not_of("helo "); // 找第一个不属于这些字符的位置这类函数在做字符分类时非常顺滑，比如解析一行文本、剥离空白、按分隔符扫描。与正则表达式相比，它们是线性查找，没有额外开销，适合轻量解析。唯一要留意的是参数含义是“字符集合”，不是“子串”，写错会得到完全不同的结果。
5.3 substr 的边界、异常和拷贝成本
substr(pos, count)从pos开始截取count个字符。如果pos越界，抛std::out_of_range；如果count超过剩余长度，就取到字符串末尾为止，不会报错。
很多教程把它描绘成“轻量操作”，这是一种误导。substr()返回的是新构造的string，内部字符数据会被完整复制。大字符串频繁substr会产生可观的拷贝成本和时间开销，尤其在一个循环里反复截取时。
现代 C++ 里，如果只是想“看一眼”某个子串而不需要长期持有，优先用std::string_view：
std::string_view sv(s); std::string_view part = sv.substr(0, 5); // 只记录起始位置和长度，不复制字符需要生成独立字符串时才用substr()。我处理日志文件时经常遇到大字符串反复截取造成内存暴涨的情况，换成string_view后内存占用直接降下来。
6. 转换与 C 接口交互：数字解析、c_str() 和 stringstream
string很少独立存在，它常常要跟数字互相转换、跟 C 接口交换数据。这些转换操作里藏着不少版本和生命周期陷阱。
6.1 数字转字符串的三种主流写法
C++11 之前，大家常用sprintf或stringstream来格式化数字。C++11 引入了std::to_string，把整数和浮点数转成字符串变得一行搞定：
std::string s1 = std::to_string(42); std::string s2 = std::to_string(3.14159);to_string底层用printf家族实现，转换浮点数时默认精度是 6 位。如果对格式有要求，比如保留两位小数、补零、科学计数法，to_string就不够用了。这时候两种处理方案：
一种是继续用stringstream，配合std::fixed、std::setprecision控制输出格式，缺点是写法略啰嗦，但可读性和灵活性都很好。
另一种是直接用 C 的snprintf生成到临时字符数组，再转成string。效率往往比stringstream高，格式控制又比to_string灵活，是很多性能敏感模块的选择。注意缓冲区长度要留够，养成传入sizeof(buf)的习惯。
6.2 字符串转数字的解析细节
C++11 提供了stoi、stol、stoll、stof、stod、stold这些解析函数。它们都可以指定起始位置和进制，但实际开发中容易忽视两个异常：解析失败时抛std::invalid_argument，数值超出范围时抛std::out_of_range。
std::string s = "123abc"; size_t pos = 0; int value = std::stoi(s, &pos); // value 是 123，pos 指向 3，'a' 之前的位置如果字符串中间混有非数字字符，stoi会尽量解析前面的数字部分，并把pos更新到停止位置。用这个特性可以做简单的前缀解析。但要小心空字符串、全非数字字符串、开头就有空格的情况，它们的行为各不相同，建议在解析前先自行判断。
std::stringstream的解析容忍度更高，比如ss >> number时会跳过前导空白，遇到非数字字符时停止。具体用哪个取决于你期望多严格。一个常见的错误是拿到用户输入后直接stoi，没做任何格式校验，结果一行恶意输入字段就把进程带崩。正确的做法是先判断内容是否符合预期格式，再转数字。
涉及进制时要注意：stoi(s, nullptr, 16)第三个参数指定进制，但字符串前缀0x的处理在不同编译器实现下略有差异。不要依赖“自动识别前缀”这种能力，尽量显式指定进制。
6.3 c_str() 返回的指针什么时候会失效
c_str()返回一个指向string内部字符缓冲区的const char*，它一定以\0结尾。但这个指针不是永久有效的，只要后续对字符串执行了任何可能导致缓冲区重分配的操作，比如追加字符超过容量、调用resize、append、push_back，甚至调用非常量版本的operator[]都可能让已取得的指针失效。
const char* p = s.c_str(); s += " extra"; // 可能重分配内存，p 变成悬空指针 printf("%s", p); // 危险还有一个常见失误：把c_str()的结果存下来，放到容器里，等字符串销毁后再去用。这个指针指向的对象已经不存在，访问它属于未定义行为。
反过来看，如果只是读操作，c_str()拿到的是稳定视图。一个值得养成的习惯是：需要长期保存字符串内容时，直接拷贝一份string，而不是保存c_str()的指针。很多接口设计上的诡异崩溃，追根溯源都是这种“保存了不该保存的指针”。
data()的语义在 C++11 之前和c_str()不同，但 C++11 之后两者都保证以\0结尾，可以认为等价。C++17 起data()对非常量版本返回char*，可以直接用来写入。写入时务必确保下标不越界，否则又回到未定义行为的坑里。
7. 这些年在 string 上看到的典型问题
前面按接口过了一遍，这里集中记录几个我在代码审查和实际排障里反复见到的问题，每一条几乎都是线上真实发生过的。
7.1 没给拼接留空间，反而频繁重分配
一个非常典型的场景是循环构造 SQL 或日志文本：
std::string query; for (auto& row : rows) { query += row.name; query += ","; }几千行数据拼接时，query内部会反复扩容。大多数实现为了摊还成本会按倍数增长，所以问题不至于失控，但在字符串特别长、循环特别多、调用特别频繁的代码路径上，重分配次数会到几十上百次。肉眼可见的现象是capacity()忽大忽小，分配器频繁调用，整体耗时上不去。
修复方式很简单：循环前估算总量并reserve()。如果实在估不准，可以先按一个较合理的初值预留，比如query.reserve(1024)，让它至少度过前几轮小规模增长。
顺带一提，有人会在循环里写query.clear()后继续追加，这个模式并没有问题，但如果用的是std::string query;每次循环新建，分配成本就完全不一样了。复用对象是减少分配的最直接手段。
7.2 迭代器、引用和指针的失效问题
重分配是各种“神秘 bug”的源头。保存了指向string内部字符的指针或迭代器，然后继续往字符串里追加内容，后续访问时就可能读到旧地址上的垃圾数据。这种问题不稳定复现，因为小字符串走 SSO、大字符串走堆分配，触发条件很随机。
我有一次排一个诡异的内存崩溃，崩溃点在一个看似安全的strcmp上。排查到最后发现，开发者先前把s.c_str()存进了全局变量，后续另一个线程往同一个string上追加日志，把底层指针换了，全局变量成了野指针。这提醒我一条规则：不要长期持有string内部数据的任何访问器，除非你能确保期间没有非 const 操作。
7.3 比较排序时忽略大小写和区域设置
std::string的==、<、compare()都是按字符的底层编码值逐字节比较的，不做大小写归一化。对 ASCII 字符来说，'A' 小于 'a'；对包含中文等非 ASCII 字符的 UTF-8 字符串，直接比较得到的顺序和“字典序”往往对不上。
需要忽略大小写时要手动转换后再比，比如std::tolower逐字符处理，或者用<cctype>里的函数做比较器。比较麻烦的是 Unicode 字符，std::tolower只处理单字节字符，不能直接处理 UTF-8 多字节序列。真要按人类语言习惯排序，需要引入 ICU 这类库或者自定义比较函数。
另一个常被忽视的点是compare()的返回值：小于 0、等于 0、大于 0，而不是简单的true/false。写成if (s.compare(t) == 0)是对的，写成if (s.compare(t))就弄反了。
7.4 版本差异：C++11 前后的行为变化
很多项目至今还在用 C++98/03 风格的写法，碰到string的一些行为差异会踩坑。比如 C++11 之后data()和c_str()行为等价，C++11 之前data()不保证以\0结尾，老代码把data()当c_str()用就会导致越界读取。
std::string的拷贝语义在引入移动语义后也变了，按值返回大字符串时可以依靠移动或者编译器的返回值优化甩掉一次拷贝，而在老标准里无论如何都会拷一份。如果你的代码既有老分支又有新分支，这种差异会导致同一个函数在两边性能表现完全不同。
还有一个小坑是std::string和字符串字面量直接拼接时的重载解析。C++11 之后写s + "abc"和"abc" + s都合法，字面量会隐式转成string。但如果两个操作数都是const char*，编译器没有可用于拼接的运算符，这也是新手常犯的编译错误。
8. 最后补一句我的使用心得
最近两年我审查过的代码里，字符串相关的 bug 占比一直不低，但绝大多数只要把size和capacity、find和find_first_of、substr和string_view这几组概念掰开来看，问题很快就能定位。
我自己写字符串密集的代码时养成了一套固定习惯：能预估长度就reserve，能传引用就传引用，能只读就用string_view，能不持有c_str()返回的指针就不持有，循环里尽量复用一个局部string而不是反复构造新对象。这些习惯不用刻意背诵，写久了自然熟练。
最后再分享一个小技巧：在编译器开启-Wall和-Wextra，很多字符串相关的越界和类型转换问题会提前暴露。如果不确定某个 API 的边界行为，写十行测试代码跑一下，比翻半天文档更直接。string这门基础课值得花一两个晚上彻底弄清楚，回报率比追那些花哨的新特性高多了。
