最安全常用的是std::string的+和+=，自动内存管理；注意const char*与string拼接顺序、nullptr检查、VS2015移动语义限制；大量拼接用ostringstream或append()；c_str()不可长期持有；data()在C++17后可写但无结尾\0；std::format需确认编译器支持。
用 std::string 的 + 和 += 最安全也最常用
绝大多数场景下，直接用 std::string 拼接就行，不用手写循环或调用 C 风格函数。它自动管理内存，不会越界，也不用担心生命周期问题。
常见错误是混用 const char* 和 std::string 时搞错顺序："hello" + s 会编译失败（字面量不能在左边加 std::string），必须写成 s + "hello" 或显式构造：std::string("hello") + s。
-
+=比+更高效，尤其拼多次时，避免临时对象反复构造析构 - 如果拼接内容里有
nullptr的const char*，std::string构造会崩溃，得先判空 - VS2015 及更早版本对移动语义支持不完整，
std::move(s1) + s2可能没优化效果
需要高性能拼接大量字符串？用 std::ostringstream 或 std::string::append()
当你要拼几十个片段、或者边计算边拼（比如日志格式化），+ 会产生一堆临时 std::string，分配开销明显。这时候 std::ostringstream 更稳，底层缓冲可复用；而 append() 比 += 多一个重载，支持指定子串范围，适合截取后拼。
-
std::ostringstream默认用std::stringbuf，但如果你提前reserve()底层 buffer（需继承定制），性能还能再压一压 -
append()接const char*时，不带长度参数会当成 C 字符串处理，遇到中间\0就停 —— 这和assign()行为一致，容易误判 - Clang libc++ 下
std::ostringstream的str()返回值可能触发一次拷贝（C++11 前无移动），Release 模式下通常被优化掉，但调试时注意看汇编
和 C API 打交道时，别直接传 std::string.c_str() 给会改内存的函数
很多老库函数（比如 snprintf、sqlite3_bind_text）要求你传入可写缓冲区或声明“我只读”。但 c_str() 返回的是 const char*，且其指向内存只在 std::string 生命周期内有效 —— 如果你把它传给异步回调、或存进结构体长期持有，后续访问就是野指针。
立即学习“C++免费学习笔记（深入）”；
- 要传给会修改内容的函数（如
gethostname），必须自己分配缓冲区：char buf[256]; gethostname(buf, sizeof(buf)); std::string s(buf); - 若函数声明“take ownership”（如某些 SQLite 绑定接口带
SQLITE_TRANSIENT），得用strdup(s.c_str())并确保对方负责释放 -
std::string.data()在 C++17 后保证返回可写指针（前提是 string 非 const 且未 shrink_to_fit），但依然不能保证结尾有\0，用前得s.push_back('\0')再取&s[0]
用 std::format（C++20）前先确认编译器和标准库支持程度
std::format 语法干净，类似 Python，但落地比想象中慢。GCC 13 默认仍用 libstdc++ 的实验性实现，MSVC 2022 17.5+ 才算基本可用，而 Clang 15 需手动链接 libc++experimental。
- 错误信息像
error: no member named 'format' in namespace 'std'，不是你写错了，是标准库没跟上 - 格式化浮点数时，默认精度行为和
printf不完全一致，{:.3f}在某些 libstdc++ 版本下会多一位舍入 - 如果项目还要兼容 C++17，别为了炫技引入
std::format，用fmt::format（第三方）反而更稳，API 几乎一致
拼接本身看似简单，但一旦牵扯到生命周期、编码边界、跨线程持有或和旧系统对接，出问题往往不在拼的动作，而在谁在什么时候释放那块内存、以及那个 \0 到底在哪。
