C++标准模板库（STL）是语言皇冠上的明珠，提供了丰富的数据结构、算法和实用工具。但正如任何强大的工具一样，STL也有一系列“陷阱”——那些容易被误用、表现反直觉、或性能特征不明显的组件。了解这些陷阱，可以帮助开发者避免常见的错误，写出更高效、更健壮的代码。
参考：https://amwtm.cn/category/entrance.html
std::vector 可能是STL中最臭名昭著的组件。表面上，它是一个存储bool的vector；实际上，它是一个模板特化，将每个bool压缩为一个比特位以节省空间。这种优化带来了严重的后果：std::vector不满足标准容器的一般要求——它的operator[]返回的不是bool&，而是一个代理对象（std::vector::reference）。这意味着你不能取vector元素的地址，不能将元素绑定到bool&引用，而且在多线程环境中，对相邻元素的修改可能相互干扰（因为它们共享同一个字节）。更糟糕的是，某些算法（如std::copy）对vector的表现可能远差于预期。最佳实践是：除非内存极其紧张，否则使用std::vector或std::deque替代。
std::list::size() 的复杂度在C++11之前是未指定的，有些实现（如GCC）使用O(n)的算法。这意味着在一个大的list上调用size()可能意外地遍历整个容器。C++11强制要求size()为O(1)，但某些实现为了保持ABI兼容性，仍然在很长一段时间内保留了O(n)的实现。虽然现代实现都满足O(1)的要求，但这个历史遗留问题提醒我们：list不是为频繁获取大小而设计的。
std::remove和erase的惯用法经常被误解。std::remove不删除元素，而是将“未被移除”的元素移到前面，返回一个新的逻辑末尾迭代器。要真正删除元素，需要结合erase使用：v.erase(std::remove(v.begin(), v.end(), value), v.end())。新手常常忘记调用erase，导致容器大小不变，只是元素被“覆盖”了。这个设计是故意的：remove只做重排，erase才做删除，两者分离允许更灵活的操作（例如，在删除前先检查被移动的元素）。
参考：https://amwtm.cn/category/balcony.html
如果key不存在，这段代码会插入一个默认值，可能不是你想要的。更安全的方式是使用find或contains（C++20）来检查存在性，或使用at（如果键不存在则抛出异常）。
std::shared_ptr的循环引用是智能指针中最常见的陷阱。两个shared_ptr互相引用，它们的引用计数永远不会降到零，导致内存泄漏。解决方案是使用std::weak_ptr打破循环。更隐蔽的是，lambda表达式捕获this时，如果lambda被存储在类的成员变量中，且lambda的生命周期与类对象绑定，也可能形成循环引用。在这种情况下，应该捕获[weak_this = weak_from_this()]。
std::async的策略歧义是另一个容易被忽视的问题。std::async有两种启动策略：std::launch::async（强制在新线程中执行）和std::launch::deferred（惰性执行，只在调用get或wait时在当前线程执行）。如果不指定策略，默认是两者取或，这意味着由实现决定是异步还是惰性执行。这可能导致不可移植的性能表现——在某些实现中，任务可能被推迟到get调用时才执行，失去了并发的意义。最佳实践是显式指定启动策略。
参考：https://amwtm.cn/category/bathroom.html
std::string的c_str()和data() 在C++11之前，data()返回的字符串不保证以空字符结尾，而c_str()保证。C++11之后，两者都保证以空字符结尾，但data()可能返回一个只读指针（直到C++17才修改为可写）。这个微妙的历史差异可能导致使用旧编译器时的兼容性问题。
std::valarray 是STL中最被忽视的组件之一。它设计用于数值计算，支持向量化的数学运算，但几乎没有人使用它，因为它的接口怪异、与STL算法不兼容、且性能不如专门的数值库（如Eigen或Blaze）。如果你看到std::valarray出现在代码中，很可能可以用std::vector或更专业的库替代。
std::set和std::map的迭代器稳定性不同于vector。插入元素不会使现有的迭代器失效，但删除元素只会使指向被删除元素的迭代器失效。这与vector的规则完全不同（插入可能导致所有迭代器失效）。理解每个容器的迭代器失效规则，对于编写正确的循环删除代码至关重要。
std::stable_sort的内存分配可能出乎意料。稳定排序需要额外的内存空间（通常等于输入大小），如果内存不足，它会回退到效率较低的算法。在某些内存受限的环境中，stable_sort可能意外地导致内存分配失败或性能崩溃。如果不要求稳定性，std::sort更安全。
std::numeric_limits的陷阱：std::numeric_limits::min()对于浮点数返回最小的正数（而非最小的负数），这与直觉相悖。要获取最小的负数（即最负的数），应该使用std::numeric_limits::lowest()（C++11）。对于整数类型，min()和lowest()相同。
std::chrono的精度陷阱：std::chrono::high_resolution_clock在不同的实现中可能有不同的精度和行为。在某些系统上，它可能是steady_clock的别名，在另一些系统上是system_clock的别名。system_clock可能受系统时间调整影响（如NTP校准），不适合测量间隔。对于性能测量，应该使用steady_clock。
std::random_shuffle已被废弃（C++14）并在C++17中移除，因为它依赖于不安全的C库函数rand。替代品是std::shuffle，它接受一个随机数生成器作为参数。使用std::default_random_engine和std::random_device可以生成高质量的随机序列。
理解这些陷阱不是为了让开发者害怕STL，而是为了更明智地使用它。大多数情况下，STL工作得非常好；只有在边界情况下，这些细节才会变得重要。当你在项目中引入一个STL组件时，花点时间阅读它的文档、了解它的复杂度保证、异常安全性、以及迭代器失效规则，这笔投资会在调试阶段得到回报。
参考：https://amwtm.cn
