c++oding="utf-8" ?>
推荐预分配后用 += 拼接：先 reserve 总长再 +=，避免多次扩容；混合类型拼接优先用 std::ostringstream，语义清晰且缓冲优化。
用 std::string 的 += 和 + 拼接，简单但要注意临时对象开销
直接用 + 连续拼接（比如 s1 + s2 + s3）在 C++ 中会生成多个临时 std::string 对象，尤其字符串多、长度大时，性能明显下降。编译器不一定能全部优化掉这些中间拷贝。
更稳妥的做法是预分配空间后用 += 累加：
std::string result; result.reserve(s1.size() + s2.size() + s3.size()); // 避免多次 realloc result += s1; result += s2; result += s3;
-
reserve()不改变size()，只提前分配内存，后续+=基本不触发扩容 - 如果拼接项数量不确定（比如 vector
），先遍历一次求总长再 reserve() - 别对空字符串调用
reserve(0)—— 虽然合法，但某些旧 libstdc++ 版本有边界行为差异
用 std::ostringstream 处理混合类型拼接最自然
当你要拼的是字符串 + 数字 + 自定义类型（比如 "user_" + id + ".log"），std::ostringstream 是最直观的选择，它重载了 ，语义清晰，且内部通常做了缓冲优化。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::ostringstream oss; oss
- 不用手动转
std::to_string()，也避免std::string构造数字的隐式转换陷阱 -
oss.str()返回新字符串，原流可复用（调用oss.str("")清空） - 注意：频繁创建/销毁
ostringstream有构造/析构开销；若循环内高频使用，建议复用对象并每次str("")
C++20 起用 std::format 最接近“优雅”的语义
std::format 是 C++20 引入的现代方案，语法类似 Python 的 str.format() 或 Rust 的 format!，类型安全、无缓冲区溢出风险，且支持格式化控制：
std::string msg = std::format("User {} logged in at {:T}", username, std::chrono::system_clock::now());
- 需要编译器支持（GCC 13+ / Clang 15+ / MSVC 19.30+），且开启
-std=c++20 - 不依赖
<iostream></iostream>，头文件是<format></format>，体积更轻 - 目前不支持自定义类型的格式化，除非显式特化
std::formatter - 比
ostringstream快（实测通常快 20%~40%），但首次调用可能有少量初始化延迟
避免用 strcat 或 strcpy 手动管理内存
原始 C 风格拼接（比如 char buf[1024]; strcpy(buf, s1.c_str()); strcat(buf, s2.c_str());）在现代 C++ 中基本没有正当理由——既不安全（缓冲区溢出）、也不灵活（长度固定）、还难维护（需手动算偏移）。
- 哪怕你确定长度够，
strcat每次都要从头找\0，O(n) 时间复杂度，而std::string::append()是 O(1) 平摊 - 跨 DLL 边界传
char*容易引发内存归属问题；std::string的 ABI 在主流 STL 实现中已稳定 - 唯一可能例外：嵌入式极端资源受限场景且禁用 STL，但这时“优雅”本身就不在目标范围内
真正影响“优雅”的从来不是语法糖，而是是否提前考虑了容量、类型混合、可读性与生命周期。用错一个 + 不会崩，但拼接逻辑散落在三处、又混着 c_str() 和裸指针，后面谁改都得先读五分钟。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
