std::shrink_to_fit 是“请求”，不是强制释放
调用 std::vector::shrink_to_fit() 或 std::string::shrink_to_fit() 只是向 标准库 “建议”释放多余内存， 不保证立即生效，也不保证释放成功。C++ 标准只规定它是“非绑定的请求”（non-binding request），底层实现可忽略。GCC libstdc++ 通常会 realloc 并复制；MSVC 的 MS STL 在多数版本中也响应，但某些嵌入式或裁剪版 STL 可能直接空实现。
- 无法通过返回值判断是否成功——该函数返回
void - 调用后
capacity()可能不变，需手动检查：vec.shrink_to_fit(); std::cout << "new capacity:" << vec.capacity() <<"n"; - 对
std::deque、std::list、std::map等容器，shrink_to_fit根本不存在（未定义）
替代方案：swap 技巧（C++11 起通用有效）
若必须强制收缩（比如处理大 vector 后需立刻归还内存给系统），最可靠方式是利用移动语义 + 临时对象 swap：
std::vector v = {/* …… 大量数据 …… */}; v.erase(v.begin() + 1000, v.end()); // 剩余少量元素，但 capacity 仍很大 std::vector(v).swap(v); // 强制重分配，capacity ≈ size 原理：构造一个仅含当前元素的临时 std::vector（其 capacity 被最小化），再与原容器交换内部指针。该技巧对 std::string 同样有效：
std::string s = "very long string……"; s.resize(5); std::string(s).swap(s); // 或写作 s.swap(std::string(s))- 注意：C++17 起
std::string的 small string optimization（SSO）可能导致 swap 不释放内存（若内容仍在栈内缓冲区） - 该操作有拷贝开销，频繁调用影响性能；仅在真正需要时使用
-
std::vector因特化实现，swap 行为可能异常，避免对其使用此技巧
std::string 的特殊行为：SSO 与 capacity() 的误导性
短字符串（如长度 ≤ 15 字节，取决于实现）常驻栈上，capacity() 返回值可能远大于 size()，但 实际并未占用堆内存。此时调用 shrink_to_fit() 或 swap 技巧都无意义——没有堆内存可释放。
立即学习“C++ 免费学习笔记（深入）”；
- 验证是否在堆上：
std::string s = std::string(1000, 'x'); // 强制堆分配 std::cout <<"on heap?" << (s.data() != &s[0]) <<"n"; // 通常为 true - SSO 下
s.capacity()可能返回 23/31/15 等固定值，和真实堆容量无关 - 不要仅凭
capacity() - size()差值判断内存浪费程度
释放内存 ≠ 立即归还 OS，尤其在多线程或 malloc 实现下
即使 vector 成功缩小了内部 buffer，底层 malloc（如 ptmalloc、jemalloc）通常不会把内存立即交还操作系统，而是保留在进程空闲链表中供后续分配复用。这意味着：
-
top或htop显示的 RSS（常驻集大小）可能完全不下降 - 在长期运行服务中，反复 shrink/expand 容器反而增加碎片，得不偿失
- 若真需归还，可考虑
malloc_trim(0)（glibc 特有，仅对主分配区有效），但风险高、不可移植
真正关键的不是“有没有 shrink”，而是“是否在合适时机分配 / 复用 / 销毁容器”。局部作用域的 vector 自动析构，比手动 shrink_to_fit 更干净。
