clear()仅清空内容不释放内存，size变为0但capacity不变；需配合shrink_to_fit()或赋值/交换才能真正释放内存，且调用后所有指针、迭代器失效。
clear() 只清内容，不释放内存
std::string::clear() 的作用是将字符串长度设为 0，但底层分配的缓冲区（capacity）通常保持不变。这意味着 s.clear() 后 s.size() 是 0，但 s.capacity() 仍是原来的值——内存没还给系统。
常见误判场景：反复拼接字符串后调用 clear()，以为能“重置内存占用”，结果发现 RSS 持续上涨。这不是 bug，是标准行为。
- 若需真正释放内存，得配合
shrink_to_fit()（C++11 起）：s.clear(); s.shrink_to_fit();
-
shrink_to_fit()是非强制请求，编译器可忽略；实际是否缩容取决于实现（如 libstdc++ 通常响应，MSVC 早期版本可能不） - 更可靠但稍重的方法：
s = std::string();
或s.swap(std::string());
—— 利用移动赋值或交换触发旧缓冲区析构
clear() 和 assign("")、erase(0) 的区别
三者都让字符串变空，但语义与开销略有不同：
-
s.clear()：最直接，语义明确，无参数，零开销，推荐首选 -
s.assign("")：会先检查右侧是否为同一对象（避免自赋），再执行拷贝逻辑，轻微额外判断 -
s.erase(0)：本质是erase(0, npos)，需计算当前长度、做边界检查，比clear()多几步
性能差异微乎其微，但 clear() 更贴近意图，也更易被编译器优化。
立即学习“C++免费学习笔记（深入）”；
clear() 后的指针/迭代器是否失效
是的，全部失效。
clear() 会令所有指向该 std::string 内容的指针、引用、迭代器立即变为悬垂（dangling）。即使 capacity 没变，内部字符数组虽未被释放，但逻辑上已不属于该对象。
- 错误写法：
auto p = &s[0]; s.clear(); std::cout << *p; // UB
- 安全做法：clear 前保存需要的数据，或 clear 后重新获取（如
&s[0]仅在s.size() > 0时有效） - 注意：
s.data()在clear()后仍返回非空指针（C++11 要求空串 data() 必须返回有效地址），但解引用它仍是未定义行为
频繁清空 string 的性能隐患
如果循环中高频调用 clear()（比如网络包解析循环），且字符串容量不断增长，最终会形成“大缓冲小内容”的状态，浪费内存并拖慢缓存局部性。
- 对策一：预估最大长度，构造时指定 capacity：
std::string buf; buf.reserve(4096);
后反复clear()不会反复 malloc - 对策二：改用栈上缓冲（如
std::array+ 手动 null 终止），避开堆管理开销 - 对策三：确认是否真需要复用——有时新建局部
string比复用一个膨胀过的更轻量（现代编译器对短字符串优化很激进）
真正容易被忽略的是：clear 本身很快，但它的“副作用”（内存滞留、迭代器失效、后续操作隐含的 capacity 判断）才是调试难点所在。
