unordered_map要求自定义类型作key时必须显式提供std::hash特化和operator==；仅定义成员hash函数无效，须在std命名空间中偏特化std::hash并重载operator==。
unordered_map 要求自定义类型必须提供 hash 和 ==
直接把自定义 struct 或 class 当作 unordered_map 的 key 会编译失败，典型错误是：error: call to implicitly-deleted default constructor of 'std::hash<mytype>'</mytype>。这是因为 unordered_map 底层依赖 std::hash 特化和 operator==，而编译器不会自动生成这些。
必须显式提供两样东西：
- 一个
std::hash的特化模板（重载哈希计算逻辑） - 一个
operator==（用于哈希冲突时精确比对）
缺一不可，哪怕只漏了 operator==，运行时查不到 key 也是常见现象。
怎么写 std::hash 特化：别用 std::hash 成员函数
很多人误以为只要给类加个 hash() 成员函数就行，但 unordered_map 不会调用它——它只认全局的 std::hash<t>::operator()</t> 特化。
立即学习“C++免费学习笔记（深入）”；
正确做法是在 std 命名空间里对你的类型做偏特化：
namespace std {
template<>
struct hash<MyPoint> {
size_t operator()(const MyPoint& p) const {
// 推荐用 std::hash 对各字段分别算，再组合
return hash<int>()(p.x) ^ (hash<int>()(p.y) << 1);
}
};
}
注意点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不能在类内部定义这个特化（C++ 标准禁止在类作用域内特化
std模板） - 异或（
^）不是万能的，两个字段值互换会导致哈希相同（如{1,2}和{2,1}），若业务要求区分顺序，改用位移+相加更稳妥 - 别用
reinterpret_cast<size_t></size_t>强转对象地址——对象可能被移动、生命周期不匹配，且不同实例地址哈希必然不同，违背哈希一致性
operator== 必须是 const 成员函数或非成员函数
unordered_map 在查找、插入时会用 == 判断 key 是否相等，如果只写了普通成员函数（非 const），或者没定义，就会报错或行为异常。
推荐写法（非成员函数，更清晰）：
bool operator==(const MyPoint& a, const MyPoint& b) {
return a.x == b.x && a.y == b.y;
}
关键细节：
- 参数必须是
const&，否则无法绑定到临时对象或 const 引用 - 返回
bool，不能是int或隐式转换类型 - 如果类有 private 成员，非成员
operator==需要声明为friend，或通过 public getter 访问
用 make_pair 初始化时容易忽略 const 引用绑定问题
往 unordered_map<mypoint int></mypoint> 插入时写 mp.insert({p, 42}) 看似没问题，但如果 MyPoint 的构造/拷贝开销大，又没定义移动构造，可能意外触发深拷贝。
更安全的做法是明确使用 std::move 或确保类型可移动：
MyPoint p{1, 2};
mp.insert({std::move(p), 42}); // 防止冗余拷贝
另外，如果 key 类型含指针或裸资源（比如 char* 字符串），哈希函数必须按内容算（如用 std::hash<:string_view></:string_view>），而不是按地址——否则相同字符串内容但不同地址会被当成不同 key。
真正麻烦的从来不是写几行特化代码，而是哈希函数和 == 的语义是否严格一致：同一个哈希值的所有对象，== 必须能穷举区分；而 == 为 true 的两个对象，哈希值必须完全相等。这点一旦出错，bug 很难复现。
