capacity() 返回当前缓冲区能容纳的字符数（不含'\0'），非已用长度或是否够用判断依据；SSO下可能不指向堆内存，多线程读取安全但不可预测realloc，reserve()才真正预分配堆空间。
capacity() 返回的是已分配但未使用的内存大小
在 C++ 中，std::string 的 capacity() 表示当前内部缓冲区能容纳的字符数（不含终止符 '\0'），它不等于已用长度 size()，也不代表“是否足够”——它只是当前堆上分配的连续空间大小。你不能靠它判断“是否够用”，只能知道“现在最多还能塞多少而不 realloc”。
常见误解是：如果 s.capacity() >= needed 就认为安全。这在多数场景下成立，但要注意：
-
capacity()是实现定义的，可能远大于size()（例如 VS 的 string 有 SSO，小字符串根本不分配堆内存，此时capacity()可能为 15 或 22，但实际不指向堆） - SSO（small string optimization）下，
capacity()仍返回“理论最大容量”，但调用reserve()后才真正触发堆分配 - 多线程中，
capacity()读取是安全的，但不能据此预测后续 append 是否会抛std::bad_alloc
reserve() 不改变 size，只预分配堆空间
如果你提前知道要追加大量字符（比如拼接 10KB 日志），用 reserve() 避免多次 realloc 是有效手段。但它不“检查”，而是“确保”：
std::string s = "prefix"; s.reserve(4096); // 确保 capacity() >= 4096；若不够则分配新内存并拷贝 // 此时 s.size() 仍是 6，但 s.capacity() 至少为 4096
注意点：
立即学习“C++免费学习笔记（深入）”；
-
reserve(n)当n 时通常无操作（C++11 起标准要求不缩减 capacity） - 传入
0不会释放内存（C++20 前没有 shrink_to_fit 的等价物） - 某些旧 libstdc++ 实现中，
reserve()在 SSO 区间内可能被忽略（比如 n=10，而 SSO 容量已是 15）
shrink_to_fit() 无法保证释放，且不解决“是否够用”问题
shrink_to_fit() 是请求缩小 capacity 到 size，但它是非强制的——标准只说“尽力而为”。它和“检查容量是否足够”完全无关，反而常被误用于“清理后看还剩多少余量”，这是错误思路。
典型误用：
s += big_data;
s.shrink_to_fit(); // 之后检查 capacity()？没意义：此时 capacity() 可能还是 > size()
if (s.capacity() > s.size() + 100) { /* 认为还有富余？错！*/ }
真正该关注的是：
- 是否即将调用
push_back()/append()/+=等可能 realloc 的操作 - 这些操作是否在性能敏感路径（如 tight loop）中频繁发生
- 是否在嵌入式或内存受限环境，需要避免不可控的堆分配
真正需要“检查是否够用”的场景，应换用更可控的方案
如果你的逻辑依赖“确定不会 realloc”，说明你已在做底层优化或对接 C API（比如把 string.data() 传给 write() 或 sqlite3_bind_text()）。这时靠 capacity() 检查很脆弱，推荐：
- 用
std::vector<char></char>替代：明确控制内存，vec.capacity()更可预测，且支持vec.data()直接使用 - 对固定上限场景，用
std::array<char n></char>+std::string_view组合，避免动态分配 - 若必须用
std::string，且需多次追加，先reserve()再循环append()，不要每次 append 前都查capacity()
SSO 和 allocator 差异让 capacity() 在不同 STL 实现中行为不一致，把它当“检查接口”本身就容易出偏差。
