Chapter 58: Common STL Mistakes

常见 STL 错误通常来自同一个根源：代码把“接口看起来还能访问”和“背后的对象仍然有效”混成了一个判断。容器、算法、视图、比较器和可调用对象包装器都在隐藏实现细节，但它们没有取消对象生命周期、内存迁移、迭代器失效、排序关系和调用成本这些约束。

本章围绕一段数据处理代码展开：程序把记录放在 std::vector 中，为了快速查询又建立 std::unordered_map 索引；随后用 std::string_view 和 ranges view 观察字段，用 std::remove_if 删除无效记录，用自定义 comparator 排序，并把筛选逻辑存进 std::function。这段代码覆盖了工程中最容易出现的五类 STL 误判。

读完本章后，读者应能执行一套固定检查：先确认被保存的是 value、iterator、reference、pointer 还是 view；再确认后续操作是否搬迁存储、擦除元素或重新分桶；接着判断算法是否真的改变容器大小；再验证比较器是否满足 strict weak ordering；最后把 std::function 放在封装收益和热路径成本之间评估。

贯穿材料如下。代码保持简化，只展示风险形状；真实工程中字段更多、调用层级更深，但判断顺序相同。

#include <algorithm>
#include <functional>
#include <string>
#include <string_view>
#include <unordered_map>
#include <vector>

struct Record {
    std::string id;
    int score{};
    bool expired{};
};

std::vector<Record> records;
std::unordered_map<std::string_view, Record*> index;
std::function<bool(const Record&)> keep;

void rebuild_index() {
    index.clear();
    for (Record& record : records) {
        index.emplace(std::string_view(record.id), &record);
    }
}

这段代码的错误空间集中在三类对象上：std::string_view 指向 record.id 内部字符；Record* 指向 records 内部元素；std::function 持有一个可复制的 callable target。只要 records 扩容、元素被移动、元素被擦除、字符串被修改、哈希表 rehash 或 callable 被放进热循环，表面接口仍能编译，语义却可能已经失效。

58.1 iterator、reference 与 view lifetime

iterator、reference、pointer 和 view 都是“位置或观察入口”，它们的有效性依赖被观察对象的生命周期和存储稳定性。std::string_view 是典型例子：它只保存字符序列的地址和长度，本身没有字符所有权。cppreference 的 basic_string_view 页面把它描述为引用一段连续字符序列的对象；因此它的安全性来自底层字符区间仍然存在。

贯穿材料中的 index 保存了 std::string_view(record.id)。这意味着哈希表中的 key 没有复制字符串内容，只观察 record.id 的当前字符存储。只要 records 中某个 Record 被移动，或者 record.id 发生重新分配，旧 view 指向的字符区间就失去语义基础。程序随后用 index.find("abc") 看到的现象可能是查找失败、命中错误内容，或在调试环境中触发内存检查。

下面的代码展示了同类问题。函数返回 std::string_view，但底层字符串在函数结束时销毁，返回值只剩地址和长度这两个已经脱离对象所有权的信息。

#include <string>
#include <string_view>

std::string_view make_view() {
    std::string local = "temporary";
    return std::string_view(local);
}

这段代码的关键不在 std::string_view 是否轻量，而在所有权关系：local 拥有字符，view 观察字符，函数返回时 local 析构，view 没有能力延长字符生命周期。安全写法应让拥有者活得更久，或直接返回 std::string。

#include <string>
#include <string_view>

std::string make_string() {
    std::string local = "temporary";
    return local;
}

std::string_view view_from_stable_owner(const std::string& owner) {
    return std::string_view(owner);
}

iterator 和 reference 也遵循同一条规则。iterator 记录的是容器中的位置，reference 和 pointer 记录的是元素对象地址；它们是否可继续使用，由容器后续操作决定。std::vector 的连续存储使 Record* 看起来像普通数组指针，但连续存储一旦重新分配，旧地址整批失效。cppreference 的 vector 页面列出 iterator invalidation：reserve 或 shrink_to_fit 改变 capacity 时会使全部迭代器失效，push_back 改变 capacity 时也会使全部迭代器失效。

ranges view 让这个问题更隐蔽。std::views::filter(records, pred) 这类对象通常保存底层 range 和谓词的观察或包装关系；如果底层 records 已被销毁或发生使位置失效的修改，view 自身仍是一个对象，但遍历时依赖的底层区间已经变化。判断 view 安全性时，先看它是否 owning，再看它引用的 range 是否仍然存在，再看遍历期间是否发生修改。

lambda 捕获同样属于 lifetime 问题。按引用捕获局部对象，再把 lambda 存进 std::function 或异步队列，会把引用带出局部作用域。按值捕获可以复制数据，但复制的是当时的对象状态；如果捕获的是 pointer 或 view，复制后的对象仍然只观察原始资源。

#include <functional>
#include <string_view>

std::function<bool(std::string_view)> make_filter() {
    std::string prefix = "user:";
    return [&](std::string_view s) {
        return s.starts_with(prefix);
    };
}

这段代码中 lambda 被返回后继续保存对 prefix 的引用，而 prefix 已经结束生命周期。稳定写法应把需要延长的状态按值捕获，并让捕获对象本身拥有资源。

#include <functional>
#include <string>
#include <string_view>

std::function<bool(std::string_view)> make_filter() {
    std::string prefix = "user:";
    return [prefix = std::move(prefix)](std::string_view s) {
        return s.starts_with(prefix);
    };
}

本节的判断顺序是：先标出表达式保存的是拥有者还是观察者；再找到观察者指向的对象；接着检查对象生命周期和存储稳定性；最后检查观察者是否被跨作用域、跨容器修改或跨异步边界保存。STL 的常见错误经常在这一步被定位出来。

58.2 vector growth 与 unordered rehash

std::vector growth 和 std::unordered_map rehash 都是“内部结构重建”操作。它们的外部接口保持容器抽象，但内部位置关系发生变化。工程中保存 iterator、pointer 或 reference 后继续修改容器时，应把这两类重建当作第一检查点。

std::vector 的核心状态可以简化成 begin、end、capacity end 三个指针。push_back 在 capacity 足够时只在尾部构造新元素；capacity 不足时会分配新连续存储，把旧元素移动或拷贝过去，再释放旧存储。这个过程改变了所有元素地址，所以旧 iterator、reference 和 pointer 全部失效。std::vector 的连续性带来了 cache locality 和数组兼容性，也带来了扩容时整体搬迁的代价。

贯穿材料里的 index 存了 Record*。这段代码在 rebuild_index() 之后如果继续向 records 追加元素，就必须重新判断旧指针是否仍然有效。

void append_record(Record record) {
    rebuild_index();

    Record* first = index.begin()->second;
    records.push_back(std::move(record));

    // first 可能已经失效，因为 push_back 可能触发 vector 重新分配。
    // 安全做法是重新查找，或在修改完成后重建 index。
}

稳定设计通常有三种方向。第一，提前 reserve 到已知上界，然后在这个容量边界内保存元素地址。这个方向仍需要在超过容量时重新建索引。第二，索引保存稳定 id 或下标，使用前重新访问 records[index]，并在 erase 后维护下标映射。第三，改用节点式容器或把对象放入独立所有权结构，例如 std::deque、std::list、std::unique_ptr<Record> 的 vector，但这些选择会改变 cache locality、遍历成本和所有权复杂度。

std::unordered_map 的 rehash 发生在 bucket 数量重建时。插入、operator[]、reserve、rehash 都可能改变 bucket array，使遍历路径和 iterator 失效。cppreference 的 unordered_map 页面列出规则：clear、rehash、reserve、赋值会使迭代器失效；插入类操作在触发 rehash 时使迭代器失效；erase 只影响被擦除的元素。该页面还说明，元素的 reference 和 pointer 在 rehash 造成 iterator 失效时通常仍保持，擦除对应元素才会使它们失效。

这个差异容易制造误判。unordered_map 的 iterator 依赖 bucket 遍历结构，rehash 改变 bucket；节点中的 key-value 对象仍在节点里，所以指向元素的 reference 或 pointer 可继续指向同一元素。vector 的 iterator、reference 和 pointer 则一起依赖连续存储地址，重新分配会整体搬迁元素。

#include <string>
#include <unordered_map>

void unordered_rehash_example() {
    std::unordered_map<std::string, int> table;
    table.emplace("a", 1);

    auto it = table.begin();
    int* value = &it->second;

    table.reserve(1024);

    // it 失效，因为 reserve 可能 rehash。
    // value 仍指向同一个元素的 mapped value，前提是该元素没有被 erase。
    *value += 1;
}

这种差异不能靠“容器是否哈希”粗略判断。可复用顺序是：先看操作是否会重建内部存储；再分别判断 iterator、reference、pointer；接着判断保存对象是否指向容器元素、元素内部资源或 bucket 遍历状态；最后决定重建索引、重新查找、保存 key、保存下标，还是调整容器选型。

58.3 remove_if 与 erase 的配合关系

std::remove_if 的名字容易让人以为容器大小已经变短。算法层面的事实是：它只在给定 iterator 区间内重排元素，并返回新逻辑尾位置；容器本身的 size() 没有变化。cppreference 的 remove / remove_if 页面说明 removing 通过移动区间元素完成，未被移除的元素被放到前部，底层序列不会缩短，返回位置到原尾部之间的元素处于 valid but unspecified state。

贯穿材料中清理过期记录应分成两步：第一步用 std::remove_if 把保留元素压到前部，得到逻辑尾；第二步调用容器的 erase 销毁尾部元素并缩短容器。只执行第一步时，records.size() 仍保持原值，后续遍历仍会访问尾部那些状态已经不适合作为业务记录的元素。

#include <algorithm>
#include <vector>

void compact_records(std::vector<Record>& records) {
    auto new_end = std::remove_if(
        records.begin(), records.end(),
        [](const Record& record) { return record.expired; }
    );

    // 此处 records.size() 尚未变小。
    records.erase(new_end, records.end());
}

这两个阶段分别属于不同抽象层。std::remove_if 是泛型算法，它只拿到 [first, last) 和谓词，无法知道底层容器是否存在 erase 成员，也无法释放节点、缩短连续数组或更新容器 size。erase 是容器成员函数，它知道容器内部结构，能销毁元素并更新状态。两者配合的形式通常称为 erase-remove idiom；C++20 以后，很多标准容器还提供非成员 std::erase 和 std::erase_if，用一个接口封装这两个阶段。

#include <vector>

void compact_records_cpp20(std::vector<Record>& records) {
    std::erase_if(records, [](const Record& record) {
        return record.expired;
    });
}

remove_if 还会影响对象状态。C++11 之后，重排通常通过 move assignment 完成；被移动到尾部区域的元素仍然是有效对象，但内容没有业务语义承诺。对 Record 来说，尾部记录的 id 可能为空、保持旧值或处于其他有效状态；代码在调用 erase 前读取这些尾部记录来做业务判断，就是把算法中间态当成了最终容器状态。

节点式关联容器还有另一条边界。有序 std::set / std::map 的元素位置由 key 和树结构维护，key 通常不可通过 iterator 修改；用 std::remove_if 去重排这类容器不符合接口条件。关联容器清理元素应使用成员 erase、C++20 std::erase_if，或先收集 key 再删除。判断依据仍是：算法是否需要给元素赋值或移动，容器元素是否允许这种修改。

本节的判断顺序是：看到 remove / remove_if 先确认它返回的是逻辑尾；再确认容器 size() 是否已经改变；接着检查尾部对象是否被业务代码读取；最后根据标准版本选择 erase(new_end, end) 或 std::erase_if。这个顺序能把“逻辑删除”和“物理缩短”拆开。

58.4 comparator 与 strict weak ordering

比较器错误会破坏排序算法和有序容器的基础不变量。STL 中的 comparator 要表达 strict weak ordering，这比“返回谁更大”更严格。按 cppreference 的 Compare named requirement，comp(a, a) 应为 false，comp(a, b) 为 true 时 comp(b, a) 应为 false，并且关系需要满足传递性；等价关系 !comp(a, b) && !comp(b, a) 也需要保持一致。

最常见错误是用 <= 写排序比较器。<= 让 comp(a, a) 为 true，直接破坏 irreflexive 条件。排序算法依赖比较结果把区间划分、交换和递归推进；比较关系自相矛盾时，算法的前提失效，输出顺序没有可靠含义。

#include <algorithm>
#include <vector>

void bad_sort(std::vector<Record>& records) {
    std::sort(records.begin(), records.end(), [](const Record& lhs, const Record& rhs) {
        return lhs.score <= rhs.score;
    });
}

稳定写法应只表达“严格排在前面”。如果 score 相等，再使用第二个字段建立确定顺序；如果两个字段都相等，比较器返回 false，让它们进入同一个等价类。

#include <algorithm>
#include <tuple>
#include <vector>

void good_sort(std::vector<Record>& records) {
    std::sort(records.begin(), records.end(), [](const Record& lhs, const Record& rhs) {
        return std::tie(lhs.score, lhs.id) < std::tie(rhs.score, rhs.id);
    });
}

有序容器中的 comparator 后果更长期。std::map 和 std::set 用 comparator 决定树中位置，也用它判断 key 是否等价。两个 key 在 comparator 下互相都不小于对方，就属于同一个等价类；std::set 会把它们当作同一个 key 语义处理。比较器如果忽略某个字段，容器就会按忽略后的等价关系存储元素；这可能是业务设计，也可能是误删数据。

#include <set>
#include <string>

struct UserKey {
    std::string tenant;
    std::string name;
};

struct CompareByNameOnly {
    bool operator()(const UserKey& lhs, const UserKey& rhs) const {
        return lhs.name < rhs.name;
    }
};

std::set<UserKey, CompareByNameOnly> users;

这段代码把 tenant 从排序关系中排除。不同 tenant 下同名用户会进入同一等价类，std::set 的唯一性判断也跟着使用这个等价类。正确与否取决于业务 key 的定义；源码层面的判断必须回到 comparator 定义的关系。

还有一类错误来自可变状态。比较器读取外部可变变量，或 key 入容器后用于比较的字段被修改，会让树中已有节点的位置和当前比较关系脱节。有序容器要求 key 在容器内保持排序语义稳定；修改排序字段应采用取出节点、修改、再插入的方式，或重建容器。C++17 的 node handle 能服务这类需求，但仍要求重新插入时按当前 comparator 建立位置。

Comparator 检查顺序是：先测试 comp(x, x)；再测试成对反向比较；接着检查三元传递性；再检查等价类是否符合业务唯一性；最后检查比较器依赖的字段和外部状态是否在容器生命周期内稳定。排序错误和有序容器查找异常都应按这个顺序排查。

58.5 std::function 性能和封装边界

std::function 的核心价值是类型擦除：调用者只关心签名，例如 bool(const Record&)，不关心目标是函数指针、lambda、函数对象还是 bind expression。cppreference 的 std::function 页面把它定义为通用多态函数包装器，可以存储、复制并调用任何满足签名要求的 CopyConstructible Callable target。这个能力适合跨模块存储回调、配置策略或延迟执行任务。

类型擦除的成本来自三个位置。第一，调用从静态目标类型变成经由擦除层间接调用，编译器更难内联具体 lambda。第二，std::function 需要管理 target 的构造、复制、移动和销毁；target 较大或实现策略需要时，可能触发动态分配。第三，std::function 是可复制包装器，捕获对象也要满足可复制语义；只可移动资源需要改用其他设计，例如模板参数、显式对象所有权，或 C++23 的 std::move_only_function。

贯穿材料中的 keep 如果只在配置阶段设置、在少量调用中使用，std::function 的封装收益通常大于成本。它能把筛选策略放进统一接口，调用方无需模板化整个模块。

#include <functional>

void set_filter(std::function<bool(const Record&)> filter) {
    keep = std::move(filter);
}

bool should_keep(const Record& record) {
    return keep ? keep(record) : true;
}

同样的设计放到每条记录的热循环里，就需要重新评估。热路径中的间接调用会限制内联，复制 std::function 还可能复制捕获状态。若谓词在编译期已知，模板参数能保留 callable 的具体类型，让优化器看到完整调用体。

#include <vector>

template <class Predicate>
int count_records(const std::vector<Record>& records, Predicate pred) {
    int count = 0;
    for (const Record& record : records) {
        if (pred(record)) {
            ++count;
        }
    }
    return count;
}

这段模板代码的代价是接口膨胀和编译期实例化增加。它适合内部热路径、短小谓词和性能敏感循环；跨 ABI 边界、插件回调、运行时策略集合更适合 std::function。工程判断应以调用频率、target 大小、复制次数、生命周期边界和 ABI 需求为证据。

std::function 还有返回引用的生命周期陷阱。cppreference 说明：返回引用的 std::function 如果由返回 prvalue 的 lambda 初始化，C++23 起这类绑定会成为 ill-formed；更早标准中可能形成悬垂引用。工程代码应给 lambda 写出明确 trailing return type，并确认返回对象的生命周期覆盖调用结果。

#include <functional>

std::function<const int&()> bad_reference_provider() {
    return [] { return 42; };
}

std::function<const int&()> good_reference_provider() {
    return []() -> const int& {
        static const int value = 42;
        return value;
    };
}

std::function 检查顺序是：先确认是否真的需要运行时多态和可复制包装；再确认 target 捕获大小、复制语义和生命周期；接着确认调用位置是否属于热路径；然后检查返回引用、空 target 调用和异常边界；最后在模板参数、函数指针、引用包装、std::move_only_function、自定义 function_ref 风格非拥有视图之间选择。这里的核心是把 std::function 放回“封装能力有成本”的工程账本。

最小自检任务

阅读下面代码，判断它包含哪些 STL 使用风险，并给出修改顺序。要求覆盖 iterator / pointer / view lifetime、vector 扩容、unordered_map rehash、remove_if、comparator 和 std::function 六个检查点。

#include <algorithm>
#include <functional>
#include <string>
#include <string_view>
#include <unordered_map>
#include <vector>

struct Record {
    std::string id;
    int score{};
    bool expired{};
};

std::vector<Record> records;
std::unordered_map<std::string_view, Record*> index;

void process(std::function<bool(const Record&)> pred) {
    index.clear();
    for (auto& record : records) {
        index.emplace(record.id, &record);
    }

    auto it = index.begin();
    records.push_back({"new", 10, false});

    auto last = std::remove_if(records.begin(), records.end(), pred);

    std::sort(records.begin(), records.end(), [](const Record& a, const Record& b) {
        return a.score <= b.score;
    });

    if (it != index.end()) {
        it->second->score += 1;
    }
}

答案要点

这段代码的第一类风险是 index 的 key 和 value 都是观察对象。std::string_view key 观察 record.id 的字符存储，Record* 观察 records 内部元素。records.push_back 可能触发扩容，扩容会搬迁全部元素，使旧 Record* 失效；元素移动还可能改变 record.id 的字符存储，使旧 view 失去语义基础。因此索引应在所有会改变 records 存储的操作之后重建，或改成拥有字符串 key 加稳定 id / 下标策略。

第二类风险是 it 属于 unordered_map iterator。代码在保存 it 后没有修改 index，所以这里没有 rehash 触发点；但判断时仍要说明：一旦后续对 index 执行 reserve、rehash 或插入并触发 rehash，it 会失效。unordered_map 的元素 pointer / reference 和 iterator 规则不同，排查时要分别判断。

第三类风险是 std::remove_if 只返回逻辑尾，没有缩短 records。代码缺少 records.erase(last, records.end())，后续排序会把尾部 valid but unspecified 的元素也纳入排序。正确顺序应在 remove 后立即 erase，再考虑重建依赖元素位置的索引。

第四类风险是 comparator 使用 <=。当 a.score == b.score 时，comp(a, b) 和 comp(b, a) 可能同时为真，并且 comp(a, a) 为真，破坏 strict weak ordering。应改成 <，并在需要确定顺序时用 std::tie(a.score, a.id) < std::tie(b.score, b.id) 这类严格关系。

第五类风险是 std::function 被按值传入。它适合运行时策略封装，但在热路径中可能带来间接调用、target 复制和分配成本。若 process 是高频内部循环，可以改成函数模板接收谓词；若确实需要运行时多态，应把 std::function 保留在边界层，并控制复制次数和捕获对象大小。

可执行修改顺序是：先完成 records 的追加、删除和排序；再用严格 comparator 排序；随后重建 index；最后使用重新获取的 iterator 或重新查找结果。所有保存到容器外部的 iterator、pointer、reference 和 view 都应在修改容器后重新获取。

本章知识点总结

观察对象：iterator、reference、pointer 和 view 都依赖被观察对象的生命周期和存储稳定性。
view 所有权：std::string_view 保存地址和长度，不拥有字符内容，安全性来自底层字符区间仍然有效。
引用捕获：lambda 按引用捕获局部对象并跨作用域保存时，会把已经结束生命周期的引用带到后续调用中。
vector 扩容：std::vector 改变 capacity 时会重新分配连续存储，旧 iterator、reference 和 pointer 全部失效。
索引重建：外部索引保存 vector 元素地址或元素内部 view 时，应在容器修改完成后重建。
rehash 边界：std::unordered_map rehash 会使 iterator 失效，但元素 pointer 和 reference 通常只在对应元素被擦除时失效。
逻辑删除：std::remove_if 只把保留元素移动到前部并返回逻辑尾，容器大小由后续 erase 改变。
尾部状态：remove_if 返回位置到原尾部之间的元素仍是有效对象，但业务语义不应继续依赖。
比较器关系：STL comparator 必须表达 strict weak ordering，<= 这类非严格关系会破坏排序前提。
等价类：有序容器用 comparator 判断 key 等价性，比较器忽略的字段不会参与唯一性区分。
状态稳定：有序容器中的 key 和 comparator 依赖状态应在容器生命周期内保持排序语义稳定。
类型擦除：std::function 通过类型擦除统一 callable 签名，同时引入间接调用、target 管理和复制成本。
热路径选择：性能敏感循环优先考虑模板谓词或静态多态，运行时策略边界适合使用 std::function。
判断顺序：先查所有权和生命周期，再查容器结构重建，再查算法是否改变 size，最后查比较关系和封装成本。

58.1 iterator、reference 与 view lifetime​

58.2 vector growth 与 unordered rehash​

58.3 remove_if 与 erase 的配合关系​

58.4 comparator 与 strict weak ordering​

58.5 std::function 性能和封装边界​

最小自检任务​

答案要点​

本章知识点总结​