unordered_map的operator[]不是纯查找。键不存在时，它会尝试插入一个映射值；在本文的string到int、默认分配器示例中，新值是0。如果用cache[key]判断是否命中，一次看似只读的查询就可能把“没有结果”变成“已有值0”。

写缓存、记忆化搜索或计数代码时，关键是保留“键不存在”和“键存在但值为0”的区别。下面用C++17完整程序核对容器大小、查找结果和加载次数，再给出find、at与下标各自适合的契约。Read in English。

一个下标表达式，改变了什么

设scores只有一项：known-zero对应0。读取scores[“absent”]也得到0，但这次读取后size从1变成2，find(“absent”)能找到新项。现在known-zero与absent的数值相等，却不能据此说两个键在查询前都存在。

C++17工作草案N4659的元素访问条款把下标操作描述为通过try_emplace取得映射值。因此，不存在的键会走插入路径；对本文使用的int值，得到零值。

问题不在于0特殊。空字符串、空容器或自定义的默认对象也可能是合法业务结果。如果只看取出的值而不看键是否存在，就把两个状态压成了一个。如果先下标读取，再用find检查是否已有项，检查会看到刚插入的键；如果用if(cache[key])判断，合法零值又会被当成未命中。这两种判断方向不同，但都没有保留查询前的存在性。

用find保留缺失状态

find返回迭代器，等于end表示没有该键。只有确认迭代器不等于end后，才能访问second。这个分支同时给出存在性和已有值，不需要先count再下标查找，也不会为了检查不存在的键新增一个占位条目。

完整程序给clean建立const引用view，再执行view.find。缺失键查询后size仍为1；已有的known-zero能被找到，second也确实为0。const视图将这个查询路径约束为不修改容器，编译器也不会允许在它上面使用unordered_map的下标接口。

如果函数只需要读取，参数可以表达为const引用。不过，const不是线程同步措施，也不能让其他线程同时修改同一容器变得安全。本文程序单线程运行，不推导并发缓存保证。这里的好处是让接口意图更清楚，而不是用一个修饰符替代所有权设计。

用at表达“这里必须已有结果”

at也不会为缺失键补一个值；它在键不存在时抛出out_of_range。程序显式捕获这一类型，并确认容器大小没有变化；对known-zero调用at，则正常得到0。它适合调用方已经建立了存在性约束，而缺失意味着当前操作不能继续的地方。

find更适合把未命中作为正常分支，例如缓存需要在未命中时加载。at更适合要求已有项的路径，例如先完成初始化，再读取一项必须存在的配置。选择时先决定“缺失是什么”，不应只因为括号或函数名更短就替换。

把加载与写入放到明确的分支里

程序里的get先find，命中就返回现有值；未命中才调用load，然后emplace。连续两次get(“item”)返回42，loads为1，cache.size为1。这里没有用0作哨兵，因此以后即使load合法返回0，也不需要把它当未命中再加载。

这个顺序还有一个可读的边界：示例中只有load完成后才会插入结果。它没有TTL、容量限制、失效策略或并发请求合并，不能直接当成生产缓存。若两个线程都需要访问，必须另行设计同步与加载协调；单线程示例通过，不是线程安全证据。

不要把“避免默认插入”误读成“所有地方都禁用下标”。频次统计中++counts[key]正是希望缺失键先得到0再加1；显式赋值cache[key]=value也可能是有意插入或覆盖。判断标准是这行代码是否允许改变键集合，而不是某个接口名称天然好或坏。

十九项检查的完整程序

下面以Apple clang 21.0.0、-std=c++17和常用警告选项编译运行，输出19 checks passed。检查覆盖缺失下标插入、合法零值、const查找、at异常、两次命中只加载一次，以及没有默认构造函数的映射类型通过find查询。程序没有访问网络，也没有做性能基准或验证跨线程行为。

#include <iostream>
#include <stdexcept>
#include <string>
#include <unordered_map>

int checks = 0;
void check(bool ok) {
    if (!ok) throw std::logic_error("check failed");
    ++checks;
}
int main() {
    std::unordered_map<std::string, int> scores{{"known-zero", 0}};
    check(scores.size() == 1);
    check(scores["absent"] == 0);
    check(scores.size() == 2);
    check(scores.find("absent") != scores.end());
    check(scores.at("known-zero") == scores.at("absent"));

    std::unordered_map<std::string, int> clean{{"known-zero", 0}};
    const auto& view = clean;
    auto missing = view.find("absent");
    check(missing == view.end());
    check(clean.size() == 1);
    auto zero = view.find("known-zero");
    check(zero != view.end());
    check(zero->second == 0);
    try {
        (void)view.at("absent");
        throw std::logic_error("at should throw");
    } catch (const std::out_of_range&) {
        check(clean.size() == 1);
    }
    check(view.at("known-zero") == 0);

    int loads = 0;
    auto load = [&] { ++loads; return 42; };
    std::unordered_map<std::string, int> cache;
    auto get = [&](const std::string& key) {
        auto it = cache.find(key);
        if (it != cache.end()) return it->second;
        int value = load();
        cache.emplace(key, value);
        return value;
    };
    check(get("item") == 42);
    check(get("item") == 42);
    check(loads == 1);
    check(cache.size() == 1);

    struct Entry {
        int value;
        explicit Entry(int v) : value(v) {}
    };
    std::unordered_map<std::string, Entry> entries;
    entries.try_emplace("item", 7);
    auto found = entries.find("item");
    check(found != entries.end());
    check(found->second.value == 7);
    check(entries.find("missing") == entries.end());
    check(entries.size() == 1);
    std::cout << checks << " checks passed\n";
}

最后的Entry只提供带参数构造。示例使用try_emplace(“item”,7)显式构造，再用find读取；没有为了查找而要求构造一个默认Entry。不要把entries[“missing”]加到这份可运行示例里：在此映射类型和默认分配器下，下标的缺失插入路径不能默认构造Entry。另存的最小负面样例已实际做语法编译，编译器报告Entry没有匹配的构造函数；该失败样例不混入上面的正向程序。

先检查语义，再考虑成本

就本文的get而言，命中路径做一次find，未命中再做一次插入操作。无序关联容器要求给查找等操作的平均与最坏复杂度不同，不能把哈希表访问概括为永远常数时间；键哈希与比较本身也有成本。本例没有测量延迟，不能从十九项正确性检查推导性能提升。

另外，意外插入不只是让size多1。插入可能引发rehash；发生rehash时迭代器会失效，而元素指针与引用不会仅因rehash而失效；不能把两者混为一谈。本文不通过解引用失效迭代器演示错误，也不保证哪一次插入恰好扩容。排查时先找意外写入，再单独核对跨插入保存的迭代器生命周期。

之前的lru_cache与重复计算讨论的是Python缓存的并发契约。这里更基础：先确定一次“查询”是否已经修改了数据结构。审查C++缓存时，保留缺失与合法值的区别，通常比先换容器更直接。

条款依据为C++17工作草案N4659的元素访问与无序关联容器要求。两幅图和十九项检查为原创教学材料；0和42均为虚构示例数据，不是服务测量结果。