多数场景下append比operator+更快，因append复用内存、避免临时对象，而+每次构造新string；但需配合reserve或RVO才能稳定发挥优势，且append重载易误用。
用 std::string::append 还是 operator+？先看性能差异
多数场景下，append 比 + 更快，尤其在循环拼接或多次追加时。因为 append 直接复用原有内存空间，而 + 每次都构造新 std::string 对象，触发额外分配和拷贝。
但注意：这个优势只在「原字符串已预留足够容量」或「编译器启用 RVO/C++17 拷贝省略」时稳定成立。否则，append 也可能触发重分配，只是比 + 少一次对象构造开销。
-
append是就地修改，不产生临时对象；+必然生成新对象 - 对短字符串（如小常量），编译器可能优化掉差别，实测几乎无感
- 若拼接后立即丢弃原字符串，用
std::move(a) + b可避免一次深拷贝
append 的常见误用：参数类型没对上
写 s.append("hello") 没问题，但 s.append(5, 'x') 和 s.append(s2) 行为完全不同——前者是重复插入字符，后者才是追加另一字符串。容易把重载函数记混，导致意外结果。
-
append(const char*)：以 null 结尾的 C 风格字符串 -
append(const std::string&)：安全复制整个字符串 -
append(size_t n, char c)：插入 n 个 c，不是“插入 n 次字符串” - 传入
std::string_view时需 C++17+，且不会隐式转换const char*
典型错误：s.append("abc", 2) 编译失败——这不是截取前 2 字符，而是试图匹配 (const char*, size_t) 重载，但该重载不存在。
立即学习“C++免费学习笔记（深入）”；
什么时候必须用 append？
当你要控制内存行为、避免临时对象、或配合 reserve 做预分配时，append 是唯一选择。比如日志缓冲、协议打包、构建 SQL 参数这类对延迟敏感或需确定性内存分配的场景。
- 先
s.reserve(1024)，再用append多次追加，可确保全程零重分配 -
operator+无法做到这点，它不接受容量提示 - 在移动语义上下文中，
s.append(std::move(other))（C++20）能触发底层数据接管，比+省一次拷贝
错误示范：s = s + "a" + "b" + "c"——这会构造三个临时 std::string，再链式拷贝，效率远低于 s.append("a").append("b").append("c")。
兼容性与隐式转换陷阱
operator+ 支持更多隐式转换，比如 std::string + const char*、const char* + std::string 都合法；但 append 只接受明确的右值或引用，不支持左值 const char* 反向拼接。
-
"hello" + s合法，但s.append("hello")合法，"hello".append(s)不合法（const char*没append成员） - 混合使用字面量和变量时，
+更灵活，但代价是多一次构造 - C++20 起
std::string支持operator+=与std::string_view，此时+=行为接近append，但语义更清晰
最易忽略的一点：调试时打印 s + "x" 很方便，但上线后高频调用要立刻换成 append 或 +=，否则堆分配压力会悄悄升高。
