如何调整std::string大小并使其容量与大小一致？

当对空std::string调用resize(17)时，GCC、Clang、MSVC都会分配超出需求的容量（30或31），而非预期的17；shrink_to_fit()仅在GCC和Clang中能将容量缩减至17，MSVC会忽略该请求；C++23的resize_and_overwrite也存在同样的容量冗余问题。以下是无需依赖shrink_to_fit的可行解决方案：

1. 直接构造指定大小的字符串 #

跳过空字符串的resize操作，直接构造目标大小的字符串：

std::string s(17, '\0');

这种方式下，字符串的size和capacity会直接匹配为17——构造时会直接分配刚好满足需求的内存，不会触发几何增长的预分配逻辑。

2. 字符串交换技巧（跨编译器可靠） #

如果必须先处理空字符串再调整大小，可以通过临时字符串交换来强制收缩容量：

std::string s;
s.resize(17);
// 临时字符串的capacity严格匹配17，交换后原字符串接管其内存
std::string(17, '\0').swap(s);

该方法在所有主流编译器中都能保证size与capacity一致，因为临时字符串是按需分配内存的。

3. 手动控制内存分配（进阶） #

利用std::allocator手动分配精确大小的内存并构造字符串（C++17及以上）：

std::allocator<char> alloc;
// 分配刚好17字节的内存
char* buf = alloc.allocate(17);
// 从已分配内存构造字符串，接管内存所有权
std::string s(buf, 17);
// 注意：字符串析构时会自动释放内存，无需手动调用deallocate

为什么resize会产生冗余容量？ #

std::string的主流实现采用几何增长策略（例如每次扩容时将容量翻倍或乘以1.5），目的是减少后续扩容的内存分配次数，提升整体性能。resize需要分配内存时，会遵循该策略分配超出请求大小的容量，而非精确匹配。

关于shrink_to_fit的局限性 #

shrink_to_fit是标准定义的非强制性请求，编译器有权忽略该操作以维持性能，MSVC的实现就选择了忽略，因此无法依赖它保证跨编译器的容量收缩效果。

C++23 resize_and_overwrite的现状 #

该函数的设计目标是减少内存分配开销，允许直接在现有内存上修改内容，但并未改变std::string的容量分配策略，因此仍会产生冗余容量。

如果以上方法都无法满足需求，你确实需要自定义字符串类，通过手动控制内存分配逻辑，确保每次分配的容量严格匹配当前所需大小。

内容的提问来源于stack exchange，提问作者Zebrafish