resize 改变字符串逻辑长度并填充或截断字符，影响 size() 和遍历；reserve 仅预分配内存、提升 capacity()，不改变 size()、内容及有效性。
resize 会改变字符串内容和逻辑长度
resize 是真正修改 std::string 的「有效字符数」的操作：它会直接截断或补零（或指定字符），影响 size()、length() 和遍历行为。
- 如果新长度小于当前
size()，末尾字符被丢弃，size()变小 - 如果新长度大于当前
size()，新增位置默认填充'\0'（或可传第二个参数指定填充字符） - 无论怎么 resize，
capacity()不变——它不触发重新分配，只操作已有缓冲区 - 注意：
resize(n, c)填充的是char，不是int；传入0会被当'\0'，不是空格
示例：
std::string s = "abc";
s.resize(5, 'x'); // s 变成 "abcxx"，size()==5，capacity() 仍是原值（如 15）
reserve 只影响 capacity，不碰 size 或内容
reserve 的唯一作用是预分配内存，确保后续 append / += / push_back 等操作在达到该容量前不会触发 reallocation。它完全不影响字符串的逻辑长度、内容、operator[] 可访问范围，也不初始化新空间。
- 调用
s.reserve(n)后，s.capacity() >= n成立，但s.size()不变 - 新增的预留空间未初始化，
s[n]（n ≥size()）是未定义行为，不能读 - 若
n ，reserve可能什么都不做（标准允许不缩容） - 想“缩容”到当前大小？用
s.shrink_to_fit()（非强制，只是提示）
示例：
std::string s = "hi";
s.reserve(100); // capacity 至少为 100，但 size() 还是 2
std::cout << s[2]; // UB！s[2] 超出有效范围
立即学习“C++免费学习笔记（深入）”；
resize 和 reserve 混用时的常见误判
很多人以为 resize 后再 reserve 能“腾出空间”，或者反过来以为 reserve 后 resize 更快——其实两者职责正交，但顺序不当容易引发误解。
- 先
reserve(1000)再resize(10)：安全，capacity 大，但字符串只有 10 字符 - 先
resize(1000)再reserve(10)：无效，reserve(10)不会降低 capacity，更不会截断内容 - 对空串
s=""调用s.resize(10)，再s[5] = 'a'：合法，因为resize已把前 10 字节置为'\0'，可写 - 对空串
s=""调用s.reserve(10)，再s[5] = 'a'：UB，s[5]不在有效范围内，且内存未初始化
性能与实际使用建议
高频拼接场景下，盲目 reserve 并不总能提速；而乱用 resize 可能引入隐藏的零填充开销或越界风险。
- 已知最终长度？优先
reserve+ 构造/assign，避免多次扩容；不要resize后反复赋值 - 需要清空并重用？
s.clear()比s.resize(0)语义更清晰（效果相同，但后者易让人误以为要填字符） - 读取 C 风格字符串？
s.c_str()总是返回以'\0'结尾的指针，但s.data()在 C++11 中不一定以'\0'结尾（C++17 起保证一致） - 调试时怀疑内存问题？检查
size()vscapacity()，别只看length()——它们一样，但capacity()才反映真实分配量
最易被忽略的一点：resize 的填充动作是逐字节构造，对含非平凡构造函数的字符类型（比如自定义 char 类型）可能有隐式开销；而 reserve 完全不涉及对象构造。
