前阵子帮人过一段日志拼装的代码，一个不到四十行的函数里同时出现了三种写法：s.push_back(c)、s.append(buf, n)、s += "]"。写这段代码的人并不是不会用，而是从来没觉得这三种方式之间有什么区别——反正都是往字符串尾巴上挂东西，哪个顺手写哪个。这种代码平时跑着也没事，直到某次批量拼装几十万条记录时出现了偶发崩溃，查下去才发现根子就在一处"自己追加自己"的写法上，扩容之后旧的指针变成了野指针。
C++ 的std::string里，append、push_back、operator+=这三个东西表面上都是"追加"，但它们在标准里的身份、重载集合、返回类型、失效规则、异常行为都不一样。搞清楚这些差别，不只是为了写出"更优雅"的代码，而是能在批量拼接、跨标准版本兼容、模板泛型编程这些场景下避开实实在在的坑。这篇东西适合两类人看：一类是刚把std::string用熟、想弄明白"到底该用哪个"的新手；另一类是在做性能敏感模块、需要判断"这里会不会多一次内存拷贝"的老手。下面我按签名、内存行为、踩坑、选型、迁移这个顺序，把三者彻底拆开讲一遍。
1. 把三者的"身份证"先亮出来
1.1 push_back 是带着容器血统过来的接口
std::string本质上是std::basic_string<char>，标准把它定位成"字符序列容器"，所以它必须满足序列容器的一批通用要求，push_back就是从这个定位里继承下来的接口。它的语义非常窄：往序列尾部压入一个元素，对字符串来说就是一个字符。签名只有一个形式，参数类型就是charT：
// C++11 到 C++17 的签名 void push_back(charT ch); // C++20 起改成了返回引用 basic_string& push_back(charT ch);这个返回类型的变化值得单独说一句。在 C++20 之前，push_back返回void，意味着s.push_back('a').push_back('b')这种链式写法压根编译不过；而append和+=一直都返回*this，天生支持链式。如果你的代码库要兼容 C++11/14/17 的编译环境，就绝对不能依赖push_back的返回值，老老实实分两行写。这里还有个细节：不同标准库实现对返回类型的跟进时间不完全一致，写跨平台代码时最稳妥的态度就是"当它是 void 用"。
从语义角度看，push_back的价值在于它明确表达"我只加一个字符"。你在读代码时看到push_back，脑子里不用做任何额外推理，就知道这里追加的粒度是一个字节。这种"意图清晰"在长期维护的代码里比省几个字符重要得多。
1.2 append 才是字符串真正的能力集合
append是basic_string自己的成员，不属于任何容器通用接口，所以它可以有非常多的重载。这些重载覆盖了字符串拼接的几乎所有形态，我把它整理成一张表，平时写代码时对照着看比较省事：
| 重载形式 | 作用 | 容易踩的点 |
|---|---|---|
append(size_type n, charT c) | 追加 n 个字符 c | 参数是"个数在前、字符在后" |
append(const basic_string& str) | 追加整串 | 自追加时行为不保证 |
append(const basic_string& str, size_type pos, size_type n = npos) | 追加 str 从 pos 起 n 个字符 | pos 越界抛out_of_range |
append(const charT* s, size_type n) | 追加 C 字符串前 n 个字符 | 不要求s以\0结尾 |
append(const charT* s) | 追加到\0之前 | 传空指针是未定义行为 |
append(InputIt first, InputIt last) | 追加任意迭代器区间 | 区间不能来自自身 |
append(initializer_list<charT> il) | C++11 起，追加花括号列表 | 用得不多但很好用 |
append(const T& t) | C++17 起，T 可转string_view | 依赖<string_view>头 |
这张表里最容易被混淆的是前四行的参数顺序。append(3, 'a')是"三个 a"，append("aaa", 3)是"字符串 aaa 的前三个字符"，两句话意思一样但写法完全相反。我在 review 代码时见过不止一次append(str, 3)被误以为是"追加三份"，实际上它走的是append(const basic_string&, size_type)这个重载，意思是"从下标 3 开始追加到结尾"。这种误解在代码上不会报错，只会默默产出错误的业务数据，属于典型的高危隐患。
C++11 加的initializer_list版本其实挺实用，比如拼装 JSON 的括号和逗号时，s.append({'[', '"'})比两次push_back读起来清爽。C++17 加的那两个模板重载则让append可以直接吃string_view，省掉一次临时string构造，这个后面第 5 节会展开。
1.3 operator+= 不是第三个实现，它只是一层壳
很多人以为+=是独立实现、性能肯定和append不一样，这是一个非常普遍的误解。operator+=是basic_string的非成员绑定运算符（实际是成员函数形式的重载），它的重载集合包括basic_string、charT、const charT*、initializer_list，C++17 之后还加了可转string_view的模板版本。它的职责就是把参数转个手，交给append或push_back去做实际工作。
以主流的开源实现为例，operator+=(const charT* s)内部就是一句return append(s);，operator+=(charT c)内部就是push_back(c)再返回*this。也就是说，s += "abc"和s.append("abc")编译出来的代码在开启优化后几乎是同一份。所以那些"+=会多构造一个临时对象所以更慢"的说法，在字符串场景下是站不住脚的——临时对象的问题主要出在s = s + "abc"这种写法上，因为operator+确实要构造一个新的临时string。
+=的真正价值是可读性。拼接多个片段时，s += "id="; s += id; s += '&';读起来最接近人脑的自然顺序。而且由于它返回*this，链式写法也很顺手。但要记住一点：+=混用不同类型的实参时，重载决议这块的坑比append更深，具体在 3.3 节讲。
1.4 三种能力放在同一张表里对比
光看签名还是抽象，把关键维度横向拉平更直观：
| 维度 | push_back | append | operator+= |
|---|---|---|---|
| 一次能加多少 | 严格一个字符 | 任意长度 | 任意长度或单字符 |
| 能否加"部分子串" | 不能 | 能，有 pos/count 版本 | 不能 |
| 能否重复 n 次同一字符 | 不能 | 能，append(n, c) | 不能 |
| 能否吃迭代器区间 | 不能 | 能 | 不能 |
| 返回值 | C++20 前 void，之后引用 | 恒返回*this | 恒返回*this |
| 语义定位 | 容器接口 | 字符串全能力 | 语法糖 |
| 实际实现 | 直接操作内部缓冲 | 直接操作内部缓冲 | 转发给前两者 |
看完这张表，选型的逻辑其实已经浮出来了：需要"一个字符"就用push_back，需要"一段"或"部分"或"重复"就用append，追求可读性顺带拼接就用+=。但真正决定代码质量的，是下面几节关于内存和失效规则的部分。
2. 性能账要算到字节和扩容次数上
2.1 追加一个字符时，底层到底发生了什么
不管走push_back还是append(1, c)，一次单字符追加在底层都包含三个动作：先检查当前size() + 1是否超过capacity()，不够就触发扩容（申请新内存、拷贝旧内容、释放旧内存）；然后把字符写进data()[size()]这个位置；最后把长度加一并补上末尾的'\0'。C++11 之后标准要求data()返回的缓冲区必须以空字符结尾，所以这个终止符的维护是强制的，不是实现自由发挥。
这里最关键的是 SSO（短字符串优化）。主流实现一般会在string对象内部留出大约 15 个字符的栈上缓冲，长度不超过这个阈值时完全不需要堆分配，push_back就是在对象内部挪一个字节，快得几乎可以忽略。一旦跨过这个边界，第一次追加就会触发堆分配，此时那一次push_back的开销比之前几十次加起来都大。所以如果你在调试时发现某次追加莫名其妙地慢，先看看是不是刚好跨过了 SSO 边界，这比怀疑编译器优化靠谱得多。
推论是：追加单个字符的摊销复杂度是 O(1)，但"摊销"两个字意味着总有几个时刻是要还债的。如果你明知道要追加几十万个字符，提前reserve一下，就能把这笔债一次性还清。这个技巧对三种写法都有效，但收益大小不一样。
2.2 追加一整段时，差别体现在"能不能一次拷完"
append在追加一整段时，有一个天然优势：它在动手之前就知道目标长度。所以实现可以先做一次容量判断，够就一次memcpy把整段搬进去，不够就按"当前长度 + 新增长度"申请新空间再搬。整个过程中容量判断只发生一次，内存拷贝只发生一次。
如果你用循环push_back来完成同样的事情，每次追加都要做一次容量判断，跨过容量边界时还要重新分配并整体搬迁。虽然摊销下来仍是线性的，但常数项明显更大，尤其是频繁跨越 15、30、60、120 这类 2 倍扩容点时。我在自己机器上做过一组粗略对比，让程序分别追加 100 万个字符，不看精确数字只看量级：
| 写法 | 相对耗时（示意） |
|---|---|
循环push_back，不 reserve | 1.0 |
循环append(1, c)，不 reserve | 约 1.0 |
循环push_back，先 reserve 到位 | 约 0.35 |
一次性append长度 100 万的字符串 | 约 0.2 |
这里的 0.35 和 0.2 说明的事情很朴素：扩容次数才是主要成本，函数选型是次要成本。reserve把扩容从几十次压到一次，收益远大于在push_back和append之间挑挑拣拣。至于第三行和第四行之间的差距，来源是append只做一次长度检查、只调一次memcpy，而循环即使不扩容也还是要走 100 万次函数调用和长度更新。
2.3 想自己验证的话，基准测试要这么写
性能这种事，别人说的都不如自己机器上跑一遍。写基准的时候有几个坑必须绕开：一是别让编译器把整段循环优化掉，最好把结果size()打印出来或者用volatile挡一下；二是别只跑一次，取多次运行的最小值，排除系统噪声；三是每个 case 的起始条件要一致，别让第一次的分配开销污染后续测量。我常用的骨架大概是这样：
#include <chrono> #include <cstdio> #include <string> #include <vector> template <class F> double bench(F f, int repeat = 20) { double best = 1e9; for (int r = 0; r < repeat; ++r) { auto t0 = std::chrono::steady_clock::now(); f(); auto t1 = std::chrono::steady_clock::now(); double ms = std::chrono::duration<double, std::milli>(t1 - t0).count(); if (ms < best) best = ms; } return best; } int main() { const int N = 1000000; const char chunk[] = "abcdefg"; double a = bench([&] { std::string s; for (int i = 0; i < N; ++i) s.push_back(chunk[i & 7]); if (s.size() != (size_t)N) std::puts("bad"); }); double b = bench([&] { std::string s; s.reserve(N); for (int i = 0; i < N; ++i) s.push_back(chunk[i & 7]); if (s.size() != (size_t)N) std::puts("bad"); }); double c = bench([&] { std::string s; std::string big(N, 'x'); s.append(big); if (s.size() != (size_t)N) std::puts("bad"); }); std::printf("plain push_back : %.3f ms\n", a); std::printf("reserved : %.3f ms\n", b); std::printf("one-shot append : %.3f ms\n", c); }跑完这组数据，多数人会发现 resize 到位的std::string s(N, 'x')加一次append是最快的，因为它连字符串内部的初始化都省掉了逐字符写入。这类小实验花二十分钟，比在论坛上看十篇"哪个更快"的帖子有用得多。
2.4 一个反直觉的结论：单字符场景下别纠结
既然+=内部转调push_back、append(1, c)和push_back在优化后生成几乎相同的指令，那单字符追加时选哪个纯粹是可读性问题，没有任何性能考量空间。我见过有人在循环里刻意把push_back改成append(1, c)说是"性能更好"，这完全是无用功，反而破坏了意图表达——append(1, c)读起来像"我要追加一段长度未知的串"，结果长度是写死的 1，误导性更强。
真正需要纠结性能的场合只有两个：一是批量追加长字符串，用append一次性完成比循环单字符强得多；二是明确知道总量时做reserve。其余情况按可读性选就行。
3. 那些年踩过的坑，一个比一个隐蔽
3.1s.append(s)到底行不行
直接给结论：不要写。标准对append的实现前提是传入的字符范围在函数执行期间必须有效，而自追加一旦触发扩容，旧缓冲区被释放，函数内部正在读的那段内存就失效了。不同标准库实现对自引用的处理程度不一样，有的在内部做了长度预判所以侥幸能跑，有的直接读越界。这种代码最讨厌的地方在于它"测试环境正常、线上偶发崩溃"，排查成本极高。
安全写法是先用一份副本兜住：
std::string s = "hello"; // 危险：自追加 // s.append(s); // 安全：先拷贝一份 std::string tmp = s; s.append(tmp); // 或者直接构造目标结果 s = s + s;operator+=的自引用同样不可靠，因为它的实现通常就是转调append。所以s += s也别写。如果确实需要"复制自身 n 次"，用循环配合临时变量最清晰：
std::string s = "ab"; std::string result; result.reserve(s.size() * 4); for (int i = 0; i < 4; ++i) result.append(s); // result == "abababab"这里reserve提前算准总量，避免中途扩容，循环体里追加的是另一个对象，完全避开了自引用的风险。
3.2 追加之后所有指针和引用都失效了
这是我在实际项目里见过最多的string相关 bug，没有之一。典型形态是把c_str()或者data()的结果缓存下来传给别的接口，中间又做了一次追加：
std::string s = "prefix:"; const char* p = s.data(); s.append(aVeryLongPayload); // 可能触发扩容，旧缓冲区已释放 std::printf("%s\n", p); // p 已悬垂string的规则很硬：任何可能导致容量变化的操作（append、push_back、+=、insert、resize变大、reserve）都会让指向元素的指针、引用、迭代器全部失效；就算没扩容，末尾位置之后的迭代器也失效了。区别在于vector的push_back大家都很警惕，而string的+=写起来太自然，容易让人忘记它同样会重新分配。
防御办法有两条：一是不缓存data()，每次用的时候现取，成本就是一次成员访问；二是如果确实需要跨调用持有，就拷贝成独立的std::string或std::string_view加上明确的"底层对象不可变"约定。第二种在接口设计上要写清楚，不然接手的人一改就出事。
顺带提一句substr返回的是新对象，不涉及失效；但std::string_view sv = s;之后再追加s，sv就悬垂了，这个坑在 C++17 项目里特别常见。
3.3s += 0与push_back(0)的重载决议差别
想让字符串末尾追加一个'\0'，最直接的念头是写s += 0;。这行代码的行为取决于编译器怎么解读那个字面量0。operator+=有两个候选：operator+=(charT)和operator+=(const charT*)。字面量0的类型是int，它既能通过整型转换变成char，又能作为空指针常量变成const char*，两条路径的转换等级相同，多数编译器会直接报"重载歧义"。
正确的写法是让意图无歧义：
std::string s; // s += 0; // 多数编译器报重载歧义 s += '\0'; // 明确追加空字符 s.push_back('\0'); // 同样明确，语义更加直白 s.append(1, '\0'); // 也明确，但略显啰嗦另一个相关的问题是窄化。push_back的参数类型是char，你往里传一个超出char表示范围的整数，比如s.push_back(300)，会发生隐式转换。在char为有符号的实现上，300 存不进 8 位，结果由一个实现决定的值兜底（较新的标准里规定为按模 2⁸ 取模）。这类代码在换平台或者换编译器版本时可能突然改变行为，属于应该被静态检查工具拦下来的写法。写数字字符时老老实实用'0' + digit或者std::to_chars，别传裸整数。
3.4append的参数顺序陷阱，比想象中更容易中招
append重载多，导致的直接后果是"参数写反了也能编译通过，但语义完全不同"。几个典型例子：
std::string s = "x"; std::string str = "0123456789"; s.append(3, 'a'); // "xaaa" —— 追加三个 a s.append("aaa", 3); // "xaaa" —— 追加 "aaa" 的前三个字符 s.append(str, 3); // "x3456789" —— 从下标 3 开始追加到结尾 s.append(str, 3, 2); // "x34" —— 从下标 3 开始取 2 个第二行和第三行只差参数类型，结果天壤之别。第三行这种"从下标开始追加到结尾"的行为，很多人第一反应会理解成"追加三份"，这是个高频误解。我的建议是：只要涉及下标，就别用两参数版本，明确写成s.append(str, 3, str.size() - 3)或者用substr拆出来，多打几个字换来的可读性完全值。
还有一个异常问题：append(str, pos, n)在pos > str.size()时抛std::out_of_range。如果你的pos来自外部输入或者计算得出，必须有边界判断。而append(const charT*, n)传空指针是未定义行为，不会抛异常，直接崩。
3.5 迭代器区间版本的隐含前提
append(first, last)能接受任意输入迭代器，这让它可以跟其他容器配合：
std::vector<char> buf = {'a', 'b', 'c'}; std::string s = "head:"; s.append(buf.begin(), buf.end()); // "head:abc"这个能力很好用，比如从一段std::vector<uint8_t>里拼字节串。但它有个前提：区间必须是有效的，且不能和s自身重叠。s.append(s.begin(), s.end())就是典型的自引用 UB，原因和 3.1 节完全一样——迭代器指向的是旧缓冲区，扩容后全部失效。
另外，迭代器版本在实现上通常是逐个字符追加，不会做批量memcpy，所以性能上弱于append(const charT*, size_type)。如果你手里有连续内存，优先换成指针加长度版本，速度差距在大数据量下是能测出来的。
4. 到底该用哪个：一份能直接抄的选型规则
4.1 按"追加内容的形态"分，这个维度最硬
不管代码风格怎么偏好，内容形态是客观的，优先级最高：
| 追加内容 | 首选 | 次选 | 说明 |
|---|---|---|---|
| 单个字符 | push_back | += | 语义最直白 |
| 一个完整字符串对象 | +=或append | — | 两者等价，看上下文 |
| 字符串的一部分 | append(str, pos, n) | +=+substr | 前者少一次临时对象 |
| 重复 n 个相同字符 | append(n, c) | 循环push_back | 前者只有一次容量检查 |
| C 风格字符串 | append(s)或+= | — | 注意别传空指针 |
| 迭代器区间 | append(first, last) | std::copy+back_inserter | 前者更短 |
| 花括号字面量列表 | append({...}) | 多次push_back | C++11 起可用 |
这张表我自己贴在便签上用了很久，尤其是在处理日志、序列化这类大量拼接的代码时，看着表写不容易选错。
4.2 按"代码意图会不会被误读"分
形态之外还有一层：这段代码半年后别人能不能一眼看懂。我在团队里推的规则很简单：
拼接固定片段用+=，因为读起来最像自然语言。比如拼 HTTP 头，s += "Content-Length: "; s += std::to_string(len); s += "\r\n";三行下来顺序清晰，不会有人误解。
处理"部分"和"重复"用append，因为这两个能力+=根本没有，用+=实现反而要绕路构造临时对象。比如"取对方字符串的后半段接上来"，直接append(other, other.size() / 2)一行搞定，用+=就得先substr出一个临时串。
单字符一律push_back，除非处在链式表达式里（比如s.append(a).append(b)这种风格统一了整段代码，那混杂一个push_back会破坏节奏，此时用append(1, c)反而更整齐）。
4.3 明确知道规模就 reserve，这条比选哪个函数都重要
前面已经论证过扩容次数是主要成本，所以真正该养成习惯的是：只要你能估出结果字符串的大致长度，进门先 reserve。拼装 SQL、JSON、日志行这类场景，长度通常是可估的（各个片段长度之和再加一点余量），一行reserve换来的是整个过程的零扩容。
reserve的语义是"保证至少能装这么多而不重新分配"，它不改变size()，也不初始化任何字符。这意味着reserve(1024)之后s[500]依然是越界访问，别把它误当成resize。这两个函数混淆导致的 bug 我也见过：有人reserve完直接用下标赋值，结果写到未初始化的区域，size()还是 0，后续追加把数据覆盖了。
还有一个实际经验：如果预估不准，宁可按"上界"估大一点。多占几百字节内存的代价，远小于中途扩容一次的整体拷贝。
4.4 什么时候干脆别用 string 拼
如果拼接是"多线程并发的"，或者"片段数量成千上万、中间还要格式化数字"，那就别在std::string上较劲了。多线程场景下每次追加都要加锁（或者每个线程各自维护一个string最后合并）；大量数字格式化的场景，std::to_chars配合预分配缓冲区比std::to_string加append少一次临时对象构造。
我的判断标准是：如果拼接逻辑超过十次追加，且其中有格式化操作，就考虑用snprintf到栈上缓冲再一次性append，或者用一个小的格式化工具函数封装。这不是说string不好，而是把"格式化"和"拼接"这两件事拆开之后，各自的代码都更短、更好测。
5. 把这套理解迁移到别的地方
5.1 vector 里没有 append，但有等价物
理解了string的这套接口分层，再看std::vector就很清楚了：它有push_back（追加一个元素）、emplace_back（原地构造一个元素）、insert(pos, first, last)（插入区间），但没有append。原因很简单——vector的元素类型任意，不存在"追加另一段同类容器的一部分"这种需要 pos/count 语义的通用需求，所以标准没有提供。
对应的写法是v.insert(v.end(), other.begin(), other.end())，这就是vector版的 append。而"重复 n 个相同值"用v.insert(v.end(), n, value)。你会发现参数顺序、语义、异常行为几乎一一对应，因为标准在这块的设计是一致的。掌握了string的这套，vector那边不用单独学。
5.2 C++17 之后，string_view 改变了追加的写法
C++17 给basic_string加了一组模板重载：
template <class T> basic_string& append(const T& t); template <class T> basic_string& append(const T& t, size_type pos, size_type n = npos); template <class T> basic_string& operator+=(const T& t);只要T能隐式转成std::string_view且不是const charT*，就走这套。这意味着s += sv;和s.append(sv);从 C++17 起都是合法的，而且不会构造临时string，直接按视图的长度拷贝。这在处理大字符串切片时性能提升很直观：老写法s += std::string(sv)要多一次堆分配加一次拷贝，新写法一步到位。
但string_view自带一个致命坑：它不拥有内存。std::string_view sv = makeTempString();这种写法里，临时string在语句结束就析构了，sv立刻悬垂。所以凡是把视图存进成员变量、放进容器、或者跨函数返回的，都要确认底层string的生命周期足够长。我在代码评审里对这条卡得很死，因为这类 bug 往往在压力测试下才暴露。
5.3 手写一个安全的批量拼接小工具
了解了三者的边界，封装一个批量拼接函数就很自然了。目标是：一次reserve、逐个append、处理任意数量参数：
#include <string> #include <string_view> #include <utility> template <class... Args> std::string concatAll(Args&&... args) { std::string s; // 粗略预估：每个参数按 16 字节算，够覆盖大部分短片段 s.reserve(sizeof...(Args) * 16); (s.append(std::string_view(std::forward<Args>(args))), ...); return s; } // 用法 // std::string line = concatAll("id=", userId, "&ts=", std::to_string(ts));这里用 C++17 的折叠表达式把每个参数依次交给append，std::string_view的构造保证std::string、const char*、string_view都能直接传进来。reserve用了个很粗的估算（参数个数乘以 16），实际项目里可以按业务调整。
要注意两个边界：一是concatAll的返回值是std::string，走移动语义，不会有额外拷贝；二是std::string_view(std::forward<Args>(args))对const char*会做一次strlen，如果参数是已经知道长度的string_view就没这个问题。所以传参时尽量传string_view而不是裸指针，能省掉重复求长度的开销。
最后分享一个我在实际项目里养成的小习惯：凡是写append或+=，先在心里问一句"这段内容是不是来自我自己"。如果答案是"是"，立刻改成显式的临时副本，或者改用std::string result = s + suffix;这种构造新对象的写法。这个习惯帮我挡掉了至少三次潜在的自引用崩溃，而这三次的共同点都是——代码看起来完全正常，跑一万次也不会出问题，只有在大数据量触发扩容的那一刻才会炸。
