不少写 C 的朋友应该有这种经历项目里需要一个键值映射第一反应是用std::map结果数据量一上来插入和查找慢得让人想摔键盘或者你想快速判断一个集合里有没有某个元素顺手写了个 vector 循环遍历结果算法题和线上服务双双超时。这时候std::unordered_map和std::unordered_set就是你真正需要的东西。这两个容器是 C11 引入的标准库哈希容器底层用的哈希表平均复杂度能做到 O(1) 的插入、查找和删除。相比std::map的 O(log n)在数据量大的场景下性能差距是肉眼可见的。但很多初学者甚至一些老手用起来还是会踩坑自定义对象做 key 编译不通过、遍历的时候 erase 导致迭代器失效、负载因子调优不当导致性能退化……这篇文章我结合自己这些年写 C 的实际经验把 unordered_map 和 unordered_set 的用法、原理、调优和避坑点一次性讲透希望能让读到的人少走几个弯路。这篇文章适合刚接触 C11/14/17 的初学者也适合平时写业务代码时只用过 map/vector 的老手。我会从设计思路讲到底层原理再给你可以直接抄的代码示例最后把我在实战中遇到过的坑和排查方法整理成速查表。不管你是准备面试、刷题还是在做服务端后台、图像处理、中间件开发这几个容器的用法都能直接落地。1. 为什么选择哈希容器unordered_map/unordered_set 的设计思路1.1 从有序到无序什么场景真正需要“哈希”很多刚开始接触 C 的人都有一个疑问std::map用得好好的为什么要搞出一个 unordered 版本关键在于“有序”这两个字带来的代价。std::map底层是红黑树每次插入和删除都要做节点分配和树的旋转调整查找时需要从根节点一路比较下去。复杂度是 O(log n)这个复杂度已经不错了但问题是它为了维持键的有序性做了很多额外工作。如果你的业务逻辑根本不关心键的顺序只关心“能不能快速找到”那这些工作就纯粹是浪费。举几个典型场景给你一堆字符串统计每个字符串出现的次数。这个场景里键的先后顺序毫无意义你只需要能在 O(1) 时间内根据某个单词找到对应的计数器。网络请求里根据请求 ID 快速找到对应的处理上下文。ID 是随机生成的顺序没有意义要的是极速定位。做去重判断比如一批 URL 中哪些已经见过了。你只需要一个存在性判断不需要排序后挨个看。在这种场景下unordered 系列容器能把 O(log n) 直接压到平均 O(1)当然前提是哈希函数质量没问题、桶数够用。另外还要提一个容易被人忽略的点std::map的 key 要求能比较大小必须重载operator。而unordered_map的 key 要求的是“能计算哈希值 能判断相等”这是两种完全不同的约束。有时候你想用自定义类型做 key但该类型根本没有自然的顺序概念强行写一个operator别提多别扭而写一个hash函数反而更贴合直觉。从内存角度多扯一句红黑树的每个节点除了存储 key/value还要额外维护几个指针父节点、左右孩子、颜色标记内存开销不小。哈希表的节点则简单得多通常就是一个链表节点加一个键值对虽然桶数组本身也有内存但总体下来在相同元素数量下unordered 系列往往比 map 更紧凑一些。1.2 底层结构哈希表怎么做到 O(1)有人把 unordered_map 想成“一个数组加一堆链表”这个理解方向是对的。它的大致套路是对 key 做一次哈希运算得到一个无符号整数再用这个整数对桶数量取模得到桶的索引。每个桶下面挂着链表标准库实现通常是单链表冲突的元素就串在这个链表里。查找的时候先算哈希值、定位到桶然后在链表里逐个比较 key 是否相等。如果哈希函数足够均匀每个桶里的元素很少平均每次查找只需要 O(1) 次比较。这里需要理解两个核心参数桶数bucket_count哈希表里数组的长度。负载因子load_factor当前元素个数 / 桶数即每个桶平均挂多少元素。当负载因子超过某个阈值标准库默认是 1.0哈希表就会扩容也就是重新分配一个更大的桶数组把所有元素重新哈希搬过去。这个过程叫 rehash。rehash 是 O(n) 的但如果均摊到每次插入上整体依然保持 O(1) 的均摊复杂度。还有一个很容易被忽略的细节标准库的哈希值计算用的是std::hashKey。对于整数、指针、字符串这些内置类型标准库提供了现成的特化版本。但如果你自定义了一个类型没有提供std::hash的特化编译期就会直接报错。这个问题我后面会专门展开讲。2. unordered_map 和 unordered_set 的用法详解2.1 头文件、声明与初始化从“能用”到“好用”用这两个容器之前头文件要引对#include unordered_map #include unordered_set注意和map、set的头文件并不一样英文里多了一个 unordered_ 前缀。这个前面已经提过。顺便提醒一句有些习惯不佳的代码会把using namespace std;直接写在头文件里我见过不少项目因为这个出过编译冲突建议在 .cpp 文件里用不要在头文件里用。最基本的声明和初始化// 基础声明 std::unordered_mapint, std::string m; std::unordered_setint s; // 列表初始化 std::unordered_mapstd::string, int wordCount { {hello, 1}, {world, 2} }; std::unordered_setint primes {2, 3, 5, 7, 11}; // 指定初始桶数减少扩容 std::unordered_mapint, int m2(100);有些人不知道可以传初始桶数。如果你预先知道要存一万个元素直接std::unordered_mapint, int m(10000);可以避免中途多次 rehash 带来的性能损耗。不过也别傻乎乎地觉得桶数越大越好桶数过大会浪费内存最好的办法是用下面的reserve。m.reserve(10000);reserve会根据你给的元素数量重新调整桶数让负载因子保持在合理范围。这个比直接构造时指定桶数更符合“为 N 个元素做准备”的语义。2.2 插入、查找、删除理解返回值才是高手插入insert和emplace都用得上。关键区别在于emplace是原地构造避免了临时对象的构造和拷贝。std::unordered_mapstd::string, int scores; // insert 方式 scores.insert({Alice, 90}); // emplace 方式原地构造 pair scores.emplace(Bob, 85);emplace的性能优势在 key 或 value 是复杂对象时比较明显。比如 value 是一个std::vectorstd::string用insert可能需要先构造一个pair再拷贝进去而emplace可以直接传入构造参数。不过有个坑emplace的参数如果写错可能构造失败或者产生意外行为。比如// 错误示范直接把字符数组传进去 scores.emplace(Alice, 90); // 没问题 scores.emplace(Alice, 90, 100); // 编译错参数多了另一个更隐蔽的坑在operator[]。很多人喜欢用m[key] value来插入但要注意如果 key 不存在operator[]会先默认构造一个 value然后再赋值。如果 value 类型构造代价高比如 shared_ptr、vector会白白多一次默认构造。// 如果 Charlie 不存在这里会先默认构造一个值为空串的 Entry scores[Charlie] 75;对于基本类型这个无所谓但如果你用unordered_mapint, std::shared_ptrSomeHeavyClass最好改用emplace或insert。查找查找最稳的是findauto it scores.find(Alice); if (it ! scores.end()) { // it-first 是 keyit-second 是 value std::cout it-second std::endl; } else { std::cout not found std::endl; }用operator[]做查找是一个常见的坑。比如int score scores[David]; // 如果 David 不存在会插入一个默认值 0这就产生了副作用本来只是查一下结果往容器里塞了一个新元素。而且如果 value 是自定义类型默认构造又跑一遍性能损耗更大。所以明确要“只读”的话用find或者at。C11 提供了at它在 key 不存在时会抛出std::out_of_range异常try { int score scores.at(David); } catch (const std::out_of_range e) { // 处理未找到的情况 }我的习惯是性能敏感路径用find逻辑上“key 一定存在”的场合用at更安全。注意at会抛异常如果你的代码开了异常禁用比如某些嵌入式环境就别用它。删除删除用erase有三种重载// 按 key 删除返回删除的元素数量0 或 1 size_t removed m.erase(Alice); // 按迭代器删除 auto it m.find(Bob); if (it ! m.end()) { m.erase(it); // 返回 voidC11/14C11 之前返回下一个迭代器 } // 删除一个范围 m.erase(m.begin(), m.end());注意 C11 标准里按迭代器删除返回的是iterator还是void存在历史版本差异。在 C11/14/17 中单迭代器版本的erase返回iteratorC11 起如此但如果你读的是很老的资料可能看到void。建议用auto it m.erase(it);这样兼容性更好但其实单迭代器版本返回的迭代器指向前一个元素还是下一个元素标准库实现不同也有细微差别。稳妥的做法是不依赖返回值在循环里先取得下一个迭代器再删除。for (auto it m.begin(); it ! m.end(); ) { if (需要删除) { it m.erase(it); // C11 起 erase 返回下一个迭代器 } else { it; } }这个细节对 unordered_map 尤其重要因为哈希容器迭代器没有“前驱”这个概念链表是单向的所以只提供“下一个”的语义。2.3 遍历、修改与 const 陷阱遍历容器是一件很自然的事for (const auto kv : m) { std::cout kv.first - kv.second std::endl; }注意范围 for 里 kv 是一个pairconst Key, Tkey 永远是 const 类型这是合理的因为修改 key 会破坏哈希表的桶结构。value 默认也是 const如果容器是 non-constkv的second是可以修改的但 key 不行。如果你想通过引用修改 value直接声明auto kv或者const auto kv根据情况来for (auto kv : m) { kv.second 10; // 直接改 value }千万别写这样的代码for (auto kv : m) { kv.first suffix; // 编译错误key 是 const }还有一个容易犯的错误在 unordered_set 里修改元素。unordered_set 的元素本身就是 key所以遍历时元素都是const的你不能通过迭代器修改元素值。因为如果随便改了哈希值就变了桶索引就不对了。如果你想“修改”某个元素标准的做法是删除它再插入一个新的。关于 const 成员函数find、count、at都有 const 版本可以安全地用在 const 引用场景void printScore(const std::unordered_mapstd::string, int m, const std::string name) { auto it m.find(name); if (it ! m.end()) { std::cout it-second std::endl; } }3. 实践中的核心细节内存与性能调优3.1 负载因子、桶数与 rehash内存换时间还是时间换内存前面提到负载因子是元素数和桶数的比值。标准库的max_load_factor()默认是 1.0。也就是说当元素个数快要超过桶数时就会触发 rehash。对一个哈希容器调优主要在以下几点bucket_count()当前桶数。load_factor()当前负载因子。max_load_factor()允许的最大负载因子默认 1.0。rehash(n)让桶数大于等于 n并重新哈希。reserve(n)让容器能容纳 n 个元素而不触发 rehash等于rehash(std::ceil(n / max_load_factor()))。你可以通过提高max_load_factor()来减少桶数、节省内存但代价是冲突增加链表变长。相反调低max_load_factor()会更快但更费内存。举个实际例子std::unordered_mapint, int m; m.max_load_factor(0.7); // 调整到 0.7让桶更宽裕 m.reserve(10000); // 提前为 10000 个元素分配足够桶数在很多追求极致性能的服务里0.7 到 0.8 是常见的选择。但不要盲目压到 0.5内存占用翻倍却不一定带来线性地性能提升。最合适的负载因子需要通过性能测试确定一般建议从默认 1.0 开始瓶颈明显时再调低。还有一点rehash的触发时机不一定是在元素个数超过阈值那一刻。标准库允许实现自己决定何时 rehash多数实现是插入导致负载因子超过max_load_factor时触发。如果插入过程中频繁 rehash整体耗时曲线会呈现锯齿状。提前reserve是消除这种锯齿抖动最有效的手段。3.2 自定义类型做 key哈希函数的重要性如果你的 key 是一个自定义结构体直接放进 unordered_map 会得到一个编译错误struct Point { int x, y; }; std::unordered_mapPoint, int m; // 编译不过这是因为标准库找不到std::hashPoint的特化。你需要自己提供哈希函数和相等比较器。第 1 种做法给std::hash写特化。namespace std { template struct hashPoint { size_t operator()(const Point p) const { size_t h1 std::hashint()(p.x); size_t h2 std::hashint()(p.y); // 组合两个哈希值简单的方式 return h1 ^ (h2 1); } }; }然后还需要定义operatorbool operator(const Point a, const Point b) { return a.x b.x a.y b.y; }这样就能直接用了。注意组合哈希值的技巧h1 ^ (h2 1)是一种常见的组合方式但如果你处理的是多个成员建议参考 Boost 的hash_combinesize_t result 0; result ^ std::hashint()(p.x) 0x9e3779b9 (result 6) (result 2); result ^ std::hashint()(p.y) 0x9e3779b9 (result 6) (result 2);这里的常量0x9e3779b9是黄金比例的无符号整数近似值能帮助把哈希值分布得更均匀。不是玄学是经过实践检验的经典技巧。第 2 种做法不修改 std 命名空间直接给 unordered_map 传入自定义哈希函数对象。struct PointHash { size_t operator()(const Point p) const { size_t h1 std::hashint()(p.x); size_t h2 std::hashint()(p.y); return h1 ^ (h2 1); } }; std::unordered_mapPoint, int, PointHash m;如果不想重载operator还可以传入自定义相等比较器struct PointEqual { bool operator()(const Point a, const Point b) const { return a.x b.x a.y b.y; } }; std::unordered_mapPoint, int, PointHash, PointEqual m;但重载operator更顺手因为很多算法标准库函数都依赖它。说到哈希函数质量还有一个著名的坑不要为自定义类型写一个弱哈希函数。比如直接把两个 int 相加size_t operator()(const Point p) const { return p.x p.y; // 极差Point{1, 2} 和 Point{2, 1} 哈希值一样 }这个哈希函数能编译但会产生大量冲突一个桶串了好几万个元素性能直接退化到 O(n)。所以做自定义 key 时一定要认真组合成员变量的哈希。3.3 迭代器失效悬挂引用不可忽视的线程与生命周期问题哈希容器有一个和 vector 不一样的地方插入元素不一定会导致原有迭代器失效。对于 unordered 系列标准库保证除非发生 rehash也就是扩容重建否则插入元素不会使现有迭代器失效而删除元素erase只会使被删除元素对应的迭代器失效其他迭代器不受影响。听起来很美好但这里有三个暗坑第一个坑删除之后继续用被删除元素的引用或指针。比如auto it m.find(key); if (it ! m.end()) { std::string ref it-second; m.erase(it); ref new value; // 未定义行为ref 已经悬挂 }如果你还要用 value先拷贝出来再删除。第二个坑循环删除时的迭代器用法。前面已经提过一定要用it m.erase(it)这种模式或者手动记录下一个迭代器for (auto it m.begin(); it ! m.end(); ) { if (条件(it)) { it m.erase(it); } else { it; } }第三个坑如果在遍历的同时插入元素可能触发 rehash导致当前迭代器失效。标准库规定 rehash 会使所有迭代器失效。所以下面这段代码是不安全的for (auto it m.begin(); it ! m.end(); it) { if (条件) { m.emplace(新key, 新value); // 可能导致 rehashit 失效 } }安全做法是先收集要插入的元素遍历完再插入或者每插入一次就重开一个新循环如果插入次数很少。同样地如果你在函数里保存了某个元素迭代器之后在别的地方插入了大量元素导致 rehash再去使用这个迭代器也是 UB。这是很多线上问题的根源。线程安全这里也提一嘴unordered 系列容器不是线程安全的多个线程同时对同一个容器进行写操作会数据竞争。常见的做法是加锁或者用并发容器库但我见过不少人误以为“读取很安全”就随意并发读如果同时有另一个线程在写读取仍然可能看到中间状态甚至崩溃。如果要做读多写少的场景可以考虑用std::shared_mutex配合容器使用。4. 常见问题与排查实录4.1 为什么自定义类型做 key 编译不过这个错误信息很长核心是找不到hash自定义类型。我的排查步骤是仔细看编译错误搜索hash或enable_hash关键词。确认是否已经在全局或std命名空间提供了特化。确认相等比较器是否可用。如果是模板类内部定义了嵌套类型还要注意特化的位置。比如在一个类里面声明了 unordered_mapkey 类型是某个内部结构体哈希特化要放在那个结构体所在的作用域。举一个比较隐蔽的错误struct Foo { struct Inner { int a; }; std::unordered_mapInner, int m; // 如果你没给 Inner 提供 hash会编译错 };你需要在std命名空间里对Foo::Inner特化hash。这个特化必须在调用之前可见最好放在类定义之前。我在项目里经常用的一组模式是这样的struct SomeKey { int id; std::string name; bool operator(const SomeKey other) const { return id other.id name other.name; } }; namespace std { template struct hashSomeKey { size_t operator()(const SomeKey k) const { size_t h1 std::hashint()(k.id); size_t h2 std::hashstd::string()(k.name); return h1 ^ (h2 1); } }; }如果你用 C20可以用三向比较运算符但这是之后的事这里不展开。4.2 迭代器失效导致的“诡异崩溃”最典型的场景是在一个循环里一边删除一边插入人就崩溃了。我之前调试过一个同事留下的代码崩溃的现场是在m.erase(it)之后又执行了it这是先释放了迭代器指向的节点再去移动迭代器。在单链表结构里it需要访问当前节点的 next 指针而当前节点已经被 delete所以你访问了已经释放的内存。正确做法有两种稳健一点的是第一种// 方式一获取下一个节点再删除 auto nextIt std::next(it); m.erase(it); it nextIt;或者// 方式二利用 erase 返回下一个迭代器C11 起 it m.erase(it);第二种更简洁但有些老编译器实现不标准建议确认编译器版本。我在 C17 下测试主流编译器都没问题。还有一个间接引用悬挂的问题const auto val m[key]; // val 是引用 m.clear(); // clear 之后 val 失效 std::cout val; // UB这种错误不好查因为不一定会立刻崩溃可能读到脏数据。尤其是你在一个函数里获取引用后来在另一个函数里清空容器仍然拿着引用操作就是典型的悬挂引用。我的经验是需要在容器多次操作之间保留数据优先用值拷贝除非你能严格保证生命周期。4.3 性能退化到 O(n)如何定位哈希冲突有时候 unordered_map 明明插入、查找都是 O(1)实时性却突然爆炸。最可能的原因就是哈希函数分布不均匀。特别是用字符串做 key 的时候一定小心劣质哈希函数。某些编译器早期版本的std::hashstd::string实现质量一般在特定模式的字符串比如都以相同前缀开头下会发生大量冲突。如果你怀疑冲突严重可以用这两个接口量化std::cout bucket_count m.bucket_count() std::endl; std::cout load_factor m.load_factor() std::endl;还可以统计每个桶的元素个数看看最大桶有多长size_t maxBucketSize 0; for (size_t i 0; i m.bucket_count(); i) { maxBucketSize std::max(maxBucketSize, m.bucket_size(i)); } std::cout max bucket size maxBucketSize std::endl;如果 maxBucketSize 很大比如超过总元素数的 5%说明哈希质量很差要去检查哈希函数的实现。排查流程我一般这样走先看负载因子如果太高可能是没 reserve导致桶数少。再看最大桶大小如果很大大概率是哈希函数的问题。如果不是内置类型检查自定义哈希是否合理。如果用字符串做 key看字符串是否都是相似前缀比如“user_1”、“user_2”有些哈希算法对这种前缀相同但结尾不同的字符串分布不均匀。这时候可以用更好的哈希函数比如FNV-1a或Murmur对长字符串再处理一下。实话说标准库的 string 哈希在现代表现还算可以但如果你做的是性能敏感的服务还是值得自己测一下。4.4 经验速查表哪些操作该用哪些容器我把自己的选择思路整理成了一张表需求场景推荐容器原因需要按顺序遍历键std::map红黑树天然有序只关心快速查找顺序无所谓std::unordered_map平均 O(1)需要范围查询比如找 [a, b) 之间的键std::map支持 lower_bound/upper_bound只关心去重顺序无所谓std::unordered_set平均 O(1)数据量极小 20 个std::vector也行避免哈希开销需要统计频率std::unordered_mapKey, int方便operator[]或emplace还有一个不少项目里喜欢用的技巧对于频繁查找但静态初始化的场景可以考虑用std::unordered_map配合reserve一次性构建好之后永不修改。这样性能很稳。如果你需要极致的查找性能可以考虑把所有键值对排好序放到std::vector里手动做二分查找数据量不大时甚至更快因为缓存友好。但这些都是后话了。对大多数人来说unordered_map 和 unordered_set 的组合已经能覆盖 90% 的场景。5. 从使用到进阶几个提高代码质量的小习惯5.1 用 find 代替 operator[] 做存在性判断判断 key 是否存在常见写法if (m.count(key)) { // ... }count可以但需要注意它对 unordered_map 来说只有 0 和 1 两种结果。性能上和find差不多但如果你想顺便拿到 value用find明显更优因为不用查两次auto it m.find(key); if (it ! m.end()) { doSomething(it-second); }另一个不太理想的写法是if (m[key] ! something) { // 你这是在插入 }这种代码在逻辑上可能碰巧正确但它会引入一个默认构造的 value污染数据。排查这种问题的时候建议先在调试器里看下 size 是否悄悄变大了。5.2 提前 reserve一次构建多次查询如果你有大量只能来一次的数据构建阶段比如从配置文件加载std::unordered_mapstd::string, int config; config.reserve(1024); // 预期 1024 个配置项 for (...) { config.emplace(name, value); }这能极大减少 rehash 次数。我测过一个场景加载 100 万条数据不 reserve 时 rehash 了十几次耗时比 reserve 后多了将近 30%。不要小看这个优化。5.3 可维护性的自定义哈希封装成公共 hash 函数如果你在项目里需要多次使用自定义类型做 key与其在std命名空间添加特化不如先定义一个公共的哈希函数工具inline size_t hashCombine(size_t seed, size_t value) { return seed ^ (value 0x9e3779b9 (seed 6) (seed 2)); } struct UserId { int64_t id; std::string tenant; // operator ... }; namespace std { template struct hashUserId { size_t operator()(const UserId uid) const { size_t seed 0; seed hashCombine(seed, std::hashint64_t()(uid.id)); seed hashCombine(seed, std::hashstd::string()(uid.tenant)); return seed; } }; }这样整个项目的哈希风格一致也方便后续扩展字段。记住加了字段之后一定要同步更新operator和哈希函数这个顺序很容易漏。我在 code review 里见过三次以上新增字段后忘了改operator结果两个对象本应不同却被认为相等数据丢失。5.4 性能分析应该靠工具而不是直觉我遇到过有人因为在循环里调用m.find几十万次觉得哈希开销大改成自己手写二分查找结果性能反而更差。所以别凭感觉优化应该先用 profiler 定位瓶颈。如果确认是哈希函数和桶数的问题再动手调整也不迟。如果只是做个对比可以在本地跑一个简单测试插入 100 万个随机整数记录耗时查找 100 万次记录耗时比较不同reserve参数下的表现。这些数据比“我觉得”可靠得多。我自己实测过在哈希函数良好的情况下unordered_map 的查找比 map 快大概 2~5 倍插入快 1.5~3 倍。但如果哈希函数很烂map 反而能吊打它。所以哈希函数的质量是这条链的命根子。6. 最后的几点心得刚才聊了很多“怎么做”最后想分享下我自己在实际项目里踩过的坑。有段时间我在做一个网关模块里面用unordered_map管理连接上下文key 是连接 ID一个整型。初期一切正常后来有一天线上出现尾延迟抖动很多请求超过几百毫秒才返回。查了半天才发现连接 ID 不是连续递增而是随机分布这个倒没问题问题出在另一块逻辑里我用字符串 key 的容器存了会话令牌那个哈希函数对特定前缀的 token 产生大量冲突导致一个桶挂了几万个节点每次查找都要遍历一条长长的链表。后来我把那个 key 类型检查了一遍重写了哈希函数并给所有 unordered 容器都调用了reserve尾延迟立刻恢复到几毫秒。那次之后我养成了习惯凡是自定义 key 或非内置 key第一件事就是检查哈希分布凡是大容器第一时间 reserve。还有一个小技巧分享给用 int 做 key 的朋友标准库对整数类型的哈希通常就是返回原值所以在连续密集的整数做 key 时冲突概率并不大但如果你把 key 设计成“总是偶数”那桶的利用率减半负载因子看起来不高但实际分布不均。这种情况下你可以考虑自己加一层混淆比如乘以一个大质数再取模能明显改善分布。最后提醒一句C17 里 unordered_map 增加了try_emplace它对构造语义的控制更精确如果 key 已存在不会构造 value能省下一笔不必要的对象开销。如果你用 C17可以优先考虑try_emplaceauto res m.try_emplace(Alice, constructExpensiveValue()); if (res.second) { // 插入成功 } else { // 已存在res.first 指向已有元素 }这个细节能帮你写出更高效、更明确的代码。unordered_map 和 unordered_set 并不难难的是理解它底层的代价和约束。只要掌握了哈希、冲突、负载因子、迭代器失效这几个关键点你基本可以放心地在生产环境中使用它们。希望这篇文章能给你省点时间少踩几个我已经踩平了的坑。
