C++中std::map异构键查找为何设计为需显式opt-in开启

要为std::map启用异构键查找，相比C++11及更早版本的写法需要额外添加少量配置，两种写法的对比如下：

int main()
{
    {
        puts("The C++11 way makes a copy...");
        std::map<std::string, int> m;
        // 传入字符串字面量时会先构造临时std::string对象，产生不必要的拷贝开销
        auto it = m.find("Olaf");
    }
    {
        puts("The C++14 way doesn't...");
        // 显式指定透明比较器std::less<>即可开启异构查找
        std::map<std::string, int, std::less<>> m;
        // 直接用字符串字面量查找，不需要构造临时std::string，无额外拷贝
        auto it = m.find("Olaf");
    }
}

很多开发者会疑惑：既然异构查找能省掉不必要的临时对象拷贝、提升查找性能，为什么标准不直接把std::map的默认比较器换成std::less<>，反而要开发者多写一段代码手动开启？核心原因有三个，都是C++标准迭代几十年踩过无数坑攒下的设计经验：

• 第一原则是绝对不破坏存量老代码：C版本迭代死守的一条底线，就是旧版本写的合法可运行代码，升级到新版本后不能平白出问题——既不能莫名编译失败，也不能悄悄改变运行逻辑。C14正式加入透明异构查找特性时，全球已经有十几年积累的天量std::map存量代码，其中不少自定义键类型的比较逻辑编写时根本没考虑跨类型比较的场景，甚至存在跨类型比较结果和键本身同类型比较结果不一致的问题。如果默认开启异构查找，这些老代码轻则直接编译报错，重则出现内部排序错乱、查找返回错误结果的隐蔽bug，影响范围根本无法兜底，因此绝对不能把异构查找设为默认行为。
• 从设计层面倒逼开发者避开隐蔽逻辑坑：异构查找能正常工作的核心前提，是跨类型比较的结果必须和键类型的同类型比较结果完全一致，严格遵守std::map排序要求的严格弱序规则。但这个前提不是所有场景都能满足：比如你自定义了一个不区分大小写的字符串作为键类型，如果默认开启异构查找，很可能随手传入普通大小写敏感的字符串字面量调用find，跨类型比较时走了默认的大小写敏感逻辑，和键本身的比较结果不一致，直接破坏map内部的红黑树排序结构，后续插入、查找都会出现随机错误，这类问题排查成本极高。把异构查找设计为显式开启的模式，相当于提前给开发者做提示：启用特性前必须先确认自己的键类型、比较逻辑真的能安全支持跨类型比较，别稀里糊涂踩坑。
• 避免意料之外的性能回退：不少人有认知误区，觉得异构查找省了临时对象拷贝，一定能提升性能，实际并非如此。有些自定义键类型的跨类型比较开销远高于同类型比较——比如需要做编码转换、格式校验、逐层比对大对象内部字段，这类场景下开启异构查找，反而比原来构造临时键做同类型比较要慢得多。如果默认开启异构查找，开发者只是升级了C++标准版本，业务代码一行没改就出现性能下跌，完全违背了加入这个特性优化性能的初衷。做成显式开启的模式，把选择权交还给开发者，自己测试过确实能获得收益再开启，不会吃无妄的性能暗亏。

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