先抛个结论：+= 和 append() 在绝大多数场景下性能完全一致，选哪个纯看可读性；但写错一行就可能掉进临时对象陷阱，导致性能暴跌数倍。
为什么 += 和 append() 性能几乎一样
两者都是 std::string 的成员函数，底层调用同一套内存追加逻辑：检查容量、必要时扩容、拷贝数据到末尾。现代标准库（libstdc++、libc++）中，operator+= 内部通常直接转发给 append() 实现。这意味着：
- 单次拼接、循环内多次拼接、预分配后拼接 —— 二者耗时无统计差异
- 都支持
const char*、std::string、char、重复次数等多种重载 - 都不会产生额外的临时
std::string对象（区别于+操作符）
append() 比 += 更值得用的三个真实场景
当需求超出简单追加时，append() 的参数灵活性立刻体现价值：
- 截取子串拼接：
s.append(other, 2, 5)—— 从other第 2 位起取 5 字符，+=做不到 - 重复字符拼接：
s.append(10, 'x')—— 追加 10 个'x'，比写s += "xxxxxxxxxx"安全且高效 - 迭代器范围拼接：
s.append(v.begin(), v.end())—— 直接消费容器，避免构造中间std::string
这些操作若强行用 +=，要么编译失败，要么得绕路构造临时对象，反而引入开销。
真正拖慢性能的其实是这三类写法
实测中，性能差距往往不出在 += vs append()，而出在误用模式：
- 写成
s = s + "a" + "b"：每次+都生成新std::string，三次分配+拷贝，比+=慢 3–5 倍 - 循环内未
reserve()：拼接总长已知时（如日志行、SQL 拼装），漏掉result.reserve(expected_total)会导致多次扩容重拷贝 - 混用
stringstream做纯字符串追加：ss << ...再ss.str()，比append()慢 4–8 倍，因流状态管理、缓冲区复制等开销
高频拼接时最容易被忽略的关键点
性能优化的临界点不在“选哪个函数”，而在“是否让内存行为可预测”：
- 拼接前估算总长度并调用
reserve()，可彻底消除扩容成本 —— 这比纠结+=还是append()重要十倍 - 连续拼接多个字面量（如
"HTTP/1.1 " + status_code + " " + reason）时，编译器在-O2下可能把+=合并为单次memcpy，但append()同样享受该优化 - 多线程环境下，每个线程应持有独立
std::string对象；共享一个string并发append()不安全，需自行加锁
