operator+ 频繁创建临时 std::string 对象是因为其左结合性导致链式调用中必须逐次构造中间结果，而改用 append()/+=、预分配 reserve() 或 std::format 可避免该开销。
为什么 operator+ 会频繁创建临时 std::string 对象
直接用 + 连接多个字符串（比如 s1 + s2 + s3）时，C++ 编译器必须从左到右求值：先构造 s1 + s2 的临时 std::string，再拿它和 s3 做一次新分配、拷贝。哪怕所有操作数都是 const char* 或 std::string_view，只要用了 +，就逃不开中间临时对象的堆分配和销毁开销。
用 std::string::append() 或 += 替代 +
把“构造新串”改成“原地追加”，就能绕过临时对象。前提是目标字符串已知容量或可预估——否则仍可能触发多次 realloc。
-
str.append(s1).append(s2).append(s3)—— 链式调用，返回引用，无临时对象 -
str += s1; str += s2; str += s3;—— 等价，语义更直白 - 如果初始
str是空的，提前调用str.reserve(total_len)能避免扩容，total_len可用s1.size() + s2.size() + s3.size()算出
用 std::string_view 配合 std::format（C++20）或自定义拼接函数
std::format 内部不依赖 +，而是通过格式化缓冲区一次性写入，天然规避中间临时串。但注意：它仍会分配最终结果字符串，只是不产生 *额外* 临时串。
-
std::string result = std::format("{}{}{}", s1, s2, s3);—— 清晰、安全、无多余临时对象（相比+链） - 若编译器不支持 C++20，可用
std::ostringstream，但它内部有流缓冲开销，不一定比reserve()+append快 -
std::string_view传参能避免隐式构造std::string，但拼接逻辑本身仍需落地为std::string，别指望只用string_view就能“拼接完还不分配”
警惕隐式转换和短生命周期临时对象
最隐蔽的开销常来自看似无害的隐式转换：比如函数返回 const char*，你直接 str + func()，func() 返回的指针会被包装成临时 std::string；又或者 std::to_string(x) + "ms"，to_string 返回的是临时 std::string，再跟字面量拼，又来一次临时对象。
- 改写为
str.append(std::to_string(x)).append("ms")，避免两次构造 - 对返回
const char*的函数，用str.append(func(), strlen(func()))绕过构造（前提是确定非 null） - 编译器可能对简单场景做 RVO/NRVO 优化，但别依赖它——尤其在模板或跨函数边界时，行为不可控
真正省掉临时对象的关键不是选某个“高级 API”，而是意识到：只要表达式中出现 + 且至少一个操作数是 std::string，就必然触发一次构造。能改 += 就别用 +，能预分配就别让 string 自己猜。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
