reserve() 比反复 += 快得多，因后者每次扩容需重新分配内存、复制旧内容、释放旧内存，而 reserve() 仅一次预分配，后续操作零拷贝。
为什么 std::string::reserve() 比反复 += 快得多
因为默认的 std::string 在每次扩容时会重新分配内存、复制旧内容、释放旧内存——典型的时间浪费。尤其在拼接几十次以上时，可能触发 5–10 次指数级扩容（如 16→32→64→128…），而 reserve() 只需一次预分配，后续所有 += 或 append() 都落在已分配内存内，零拷贝。
常见错误现象：std::string s; for (int i = 0; i 运行慢且内存碎片多；但若提前知道总长（或估算上限），<code>s.reserve(total_len) 后再拼，耗时常可降为 1/3 以内。
- 估算总长比精确计算更重要：宁可多 reserve 10%，也不要少——少则仍会扩容
-
reserve()不改变size()，只影响capacity()；调用后size() == 0仍是合法状态 - 若拼接前已含内容（如初始化为
"header:"），记得把这部分长度也计入 reserve 总量
如何安全估算拼接总长度（避免过度分配）
硬算每个子串长度 + 分隔符长度是最稳的方式，尤其当子串来源可控（如固定格式的数字、枚举名、路径片段）。别依赖 strlen 或临时构造 std::string 来测长——那本身就有开销。
使用场景：日志组装、JSON 字段拼接、SQL INSERT VALUES 列表生成。
立即学习“C++免费学习笔记（深入）”；
- 对数字转字符串：用
std::to_string(x).size()是直观但非最优；更轻量的是用模板函数或查表法估算位数（如x ） - 对 C 风格字符串字面量（如
"key="），直接用sizeof("key=") - 1，编译期常量，零运行时成本 - 若有 N 个子串，中间用单字符分隔符（如
','），总长 =sum(len_i) + (N-1) * 1；若分隔符是", "，则乘以 2
reserve() 后用 append() 还是 +=？
二者在已 reserve 的情况下性能几乎无差别，底层都走同一段不检查容量的追加逻辑。但 append() 更明确表达“批量追加”意图，且支持更多重载（如指定子串区间 append(s, pos, len)），可减少临时对象。
容易踩的坑：s += std::string("abc") 会构造临时对象再移动；而 s.append("abc") 直接读 C 字符串字面量，无构造开销。
- 优先用
append(const char*, size_t)或append(std::string_view)（C++17 起），避免隐式转换 - 若子串来自
std::string变量，直接s.append(other)即可，现代标准库会自动 move - 不要在循环里反复调用
reserve()——它不幂等，多次调用可能触发多余重分配
极端情况：拼接长度完全未知，又想避免频繁扩容
这时可分两轮：第一轮遍历只累加长度（不拼），第二轮 reserve() 后再真正拼。适用于子串生成代价低、但数量大且长度差异大的场景（如解析 CSV 行中不定长字段）。
注意：如果子串生成本身有副作用（如 IO、计数器自增），就不能拆成两轮——必须改用其他策略，比如按块 reserve（如每 100 个子串 reserve 一次），或改用 std::vector<char></char> 手动管理缓冲区。
- 两轮法示例：
size_t total = 0; for (auto& x : parts) total += x.size() + 1; s.reserve(total); for (auto& x : parts) { s.append(x); s.push_back(','); } -
std::vector<char></char>方案更底层但可控：先resize()或reserve()，用data()获取裸指针传给 sprintf / memcpy，最后构造 string 时用string(buf.data(), buf.size()) - 别忘了预留结尾 '\0' ——
std::string不需要，但vector<char></char>手动管理时若要兼容 C 接口就得留
最易被忽略的一点：reserve 的值若超过 max_size()（通常是 size_t 最大值的一半），会抛 std::length_error。生产环境里，对用户输入或外部数据做拼接前，务必加长度上限检查，而不是无脑 reserve。
