优先用 std::string_view 替代 const std::string& 作只读参数，避免隐式构造；返回字符串时依赖 RVO 和显式 move；预分配容量 reserve() 减少重分配；避免隐式转换和临时 string 构造。
用 std::string_view 替代 const std::string& 作只读参数
传参时用 const std::string& 看似避免拷贝，但调用方若传入字面量（如 "hello"）或临时对象，编译器仍可能隐式构造 std::string——这是一次堆分配 + 拷贝。改用 std::string_view 后，字面量、std::string、C 风格字符串都能零成本适配。
实操建议：
- 函数只读访问字符串内容时，优先声明为
void func(std::string_view s) - 注意生命周期：
std::string_view不拥有数据，确保它引用的原始字符串在视图使用期间不被销毁 - 避免对
std::string_view调用.data()后长期缓存指针——底层可能为栈上字面量，也可能为堆上std::string，不可假设稳定性
移动语义要显式触发，别依赖编译器自动优化
返回局部 std::string 时，编译器通常能 RVO（返回值优化），但并非总生效；而接收方若用 = 赋值而非 = std::move(...)，可能触发不必要的拷贝。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 写
std::string s = get_string();—— RVO 可能生效，但不可靠 - 写
std::string s; s = get_string();—— 必然先默认构造，再赋值，至少一次拷贝（除非赋值运算符重载为移动）
实操建议：
- 返回字符串的函数，直接
return std::string{...}或拼接结果，让 RVO 和移动构造共同起作用 - 接收方明确需要转移所有权时，写
s = std::move(get_string());，强制触发移动赋值 - 禁用拷贝（如日志缓冲类）可显式
= delete拷贝构造/赋值，只留移动接口
预分配容量 + reserve() 减少多次重分配
std::string 动态增长时会重新分配内存、拷贝旧内容。频繁 += 或 append() 小片段（如循环拼接 JSON 字段）极易触发多次 realloc + memcpy。
使用场景：
- 已知最终长度上限（如生成固定格式日志、序列化结构体）
- 批量拼接来自容器的字符串（可用
std::accumulate+ 预估总长）
实操建议：
- 初始化后立刻调用
s.reserve(expected_size)，比反复+=快 2–5 倍（取决于增长次数） - 不确定大小时，用指数扩容策略模拟：每次不够就
reserve(2 * capacity)，比线性增长更稳 - 注意：
reserve()不改变size()，也不初始化内存；resize()才会填充字符，慎用
避免隐式转换和临时 std::string 构造
以下写法看着简洁，实际每行都新建并销毁一个临时 std::string：
std::string s = "a" + std::string("b") + "c"; // 两次临时构造
s += std::to_string(42); // to_string 返回临时 string
s.append(std::string(10, 'x')); // 明确构造临时对象性能损耗集中在堆分配/释放 + 字符拷贝，尤其在 tight loop 中放大。
实操建议：
- 用
std::string_view+std::string::append(string_view)组合替代字面量拼接 -
std::to_chars（C++17）替代std::to_string，写入预分配 buffer，零分配 - 字符串字面量拼接交给编译器：
"a" "b" "c"是单个 C 字符串，不是运行时拼接
真正影响性能的往往不是单次拷贝，而是分配器行为、CPU 缓存局部性、以及多个小拷贝叠加引发的内存碎片。测之前先用 perf record -e cache-misses 或 VTune 确认是不是字符串路径热点——有时候把 std::string 换成 std::array 或静态 buffer 更直接。
