哈希表原理与字符串哈希:从STL选型到竞赛防卡实战
1. 这个考点别人背模板你该懂原理带信奥赛提高组这几年我见的最多的一幕就是学生拿到一道题一看要判重、要统计出现次数立马甩出unordered_map然后TLE了盯着超时的红色大叉一脸茫然。问他为什么慢答不上来。问他知道哈希表底层是什么吗更答不上来。哈希表在CSP-S里属于“默认你会、默认必考”的东西。它不是一个单独的考点而是嵌在字符串、图论、DP、搜索里的基础工具。你不把它吃透别人用哈希O(1)过的题你的map是O(log n)数据一大就是成倍的差距别人用字符串哈希O(n)解决匹配问题你只会KMP硬套稍微变形就死掉。这篇东西我按信奥赛提高组的实际需要来写不搞教科书式的“什么是哈希函数”直接切到竞赛场景哈希表怎么选型、怎么手写、怎么防被卡、字符串哈希的公式怎么推、什么时候该用哈希什么时候不该用。看完你能直接用也能给队友讲明白。2. 先把哈希表在竞赛里的真实定位搞清楚2.1 哈希到底是什么别把它想玄了哈希的核心就一句话把一个大的值域映射到一个小的值域。比如你有一堆坐标x 的范围是[0, 10^9]你不可能开一个10^9大小的数组去直接寻址那就把一个坐标(x, y)通过一个函数算出一个数组下标把数据塞进这个小数组里。生活类比学校有一万个学生学号是九位数不可能开一个九位数的柜子。哈希就是按“最后两位”把学生分到100个柜子里。取最后两位就是最简单的哈希函数。但取最后两位会撞车这就是冲突。解决冲突的办法就是哈希表设计的核心。竞赛里你接触到的哈希基本就四大用途用途典型场景常用工具判重DFS记忆化、走迷宫状态去重、环检测unordered_set/ 手写bool哈希计数统计众数、频次、词频unordered_map/ 手写cnt桶键值映射坐标压缩、离散化、数据结构映射unordered_map/ sortunique字符串匹配子串比较、回文判定、LCP字符串哈希进制哈希你注意看前三个用unordered_map就能搞定第四个必须手写字符串哈希。CSP-S 里真正考哈希技术含量的绝大多数是第四个因为它往往不是单独一道题而是藏在字符串题、DP优化、数据结构题里。2.2 为什么竞赛里哈希表能“O(1)”而平衡树只能O(log n)这一点我每次讲课都要强调。哈希表的查找过程是用关键字算出下标直接到数组那个位置看一眼。数组随机访问是O(1)所以理论上哈希表全程O(1)。但这里有个“平均”二字。最坏情况下所有元素都冲突到同一个桶里那就退化成链表遍历O(n)。这也是为什么竞赛题会专门设计数据来卡unordered_map——它默认用的哈希函数在某些特定输入下会产生大量冲突。所以你不仅要会写哈希还要会“防卡”。平衡树map每一步走二分严格O(log n)没有退化风险。但代价是常数大一次查找几十次内存跳转。在n 10^6的场景下O(log n)和O(1)的差距可能从 0.5 秒拉大到 2 秒多直接决定你能不能过。CSP-S 的实际经验是能用哈希的题就别用 map除非数据量极小或者你明确知道哈希会被卡。3. STL三兄弟到底怎么选选不好就是TLE的命3.1map和unordered_map的区别值决定你的命运很多新手分不清map和unordered_map看哪个都能当字典用就随便选。差在哪map底层红黑树元素有序lower_bound、upper_bound随手用但单次操作O(log n)常数巨大。unordered_map底层哈希表平均O(1)但元素无序不能二分。竞赛里的选择规则很简单需要按顺序遍历键或者查前驱后继比如区间端点动态维护——用map。只要查存在不存在、查对应值、统计次数——无脑unordered_map。map还有一个隐性开销它每个节点是动态分配的内存插入10^6个节点光内存分配的时间就够你喝一壶。unordered_map底层是连续内存桶 冲突链表插入少很多次 new。我在2023年带学生打一场模拟赛有一题n 10^6的计数题用map交上去 2.4 秒 TLE换成unordered_map直接 0.6 秒过。差距就是这么大不是玄学。3.2unordered_map自定义哈希函数防Hack必修CSP-S 是CCF出题正常情况下出题人不会恶意卡你但有些模拟赛、线上赛比如洛谷的Hack数据会专门针对unordered_map构造冲突数据。原理是 STL 默认的std::hash对int类型用的是恒等映射而unordered_map桶数量一般取质数模当你的键恰好都是模数的倍数附近时全挤到同一个桶。防卡手段有三层第一层用unordered_map时手动指定一个“混合良好”的哈希函数。比如struct CustomHash { static uint64_t splitmix64(uint64_t x) { x 0x9e3779b97f4a7c15; x (x ^ (x 30)) * 0xbf58476d1ce4e5b9; x (x ^ (x 27)) * 0x94d049bb133111eb; return x ^ (x 31); } size_t operator()(uint64_t x) const { static const uint64_t FIXED_RANDOM chrono::steady_clock::now().time_since_epoch().count(); return splitmix64(x FIXED_RANDOM); } }; unordered_maplong long, int, CustomHash mp;这个splitmix64是竞赛圈流传最广的防卡哈希原理是把一个数的每一位都“搅匀”——相当于洗牌让任何连续的数都均匀散落到不同桶里。实测效果非常稳。第二层能用long long别用string当键。unordered_mapstring, int每次查找要对整个字符串算哈希O(len)成本就算哈希函数再快也被长度拖累。能预处理成整数比如进制哈希成一个long long后面讲就用整数。第三层键数量巨大且只需判断存在性时直接手写哈希表不走 STL。3.3unordered_map的 reserve 和 max_load_factor很多人不知道的调优unordered_map默认负载因子是 1.0即桶快满时才扩容。扩容时要把所有旧元素重新哈希一遍这是隐藏的O(n)开销。如果你的程序是“一次插入完后面只查询”那扩容代价逃不掉。解决办法是先预测规模unordered_mapint, int mp; mp.reserve(1000000); // 预留100万个桶 mp.max_load_factor(0.7); // 超过70%就提前扩容减少冲突reserve直接一次性开好内存避免扩容的反复 rehash。max_load_factor调低意味着桶更多、冲突更少代价是内存更大。竞赛内存通常 256MB 或 512MB开 1e6 的桶完全没压力。我个人的经验只要事先能估算键的数量级就老老实实 reserve。不能估算的时候才放任它自动扩容。4. 手写哈希表模板两个版本吃遍竞赛4.1 什么时候必须手写STL不够用的三种情况unordered_map虽然方便但有几个致命弱点常数太大。一次查找要算哈希、查桶、查链表、比 key。比手写数组直接visit[x]慢一个量级。无法直接哈希pairint,int、tuple之类的复合键虽然可以自定义哈希但写起来麻烦而且每次构造临时对象有开销。当你需要把“键”本身也存下来比如哈希的是字符串转成的整数你还得反向查原始字符串STL 的unordered_map不够灵活。竞赛里手写哈希表90% 是用于整数键的判重/计数。下面直接给出两个我常用的模板。4.2 拉链法模板最推荐适用90%场景拉链法思想开一个数组head作为桶每个桶挂一个链表用数组模拟链表。插入和查找都先算idx key % mod然后在该桶的链表里遍历。const int MOD 1000003; // 取一个大于数据规模的质数 const int MAXN 2000005; int head[MOD], nxt[MAXN], key[MAXN], val[MAXN], tot; int find(int k) { int idx k % MOD; if (idx 0) idx MOD; for (int i head[idx]; i; i nxt[i]) { if (key[i] k) return i; } return 0; // 返回0表示不存在 } void insert(int k, int v) { int idx k % MOD; if (idx 0) idx MOD; tot; key[tot] k; val[tot] v; nxt[tot] head[idx]; head[idx] tot; }注意几个细节tot从 1 开始0 作为“空指针”数组模拟链表省去指针的new开销。idx 0的判断必须有——C 里负数取模是负数你肯定不想访问负下标。这个模板插入时是头插法新元素插到链表头部查找时优先命中最近插入的局部性好一些。这个版本的空间复杂度是O(n)查找平均O(1)。在n 5e5时比unordered_map快 3 到 5 倍是常态。4.3 开放寻址法模板省内存适用开大数组的场景开放寻址法的思想线性探测数组里只有一个大数组插入时如果桶被占了就顺着往下找空位查的时候也顺着往下找。优点是只用一块连续内存不需要额外存链表缺点是负载因子不能太高超过 0.7 性能急剧下降。const int MAXH 2000000; int key[MAXH], val[MAXH]; bool used[MAXH]; int h(int k) { int idx k % MAXH; if (idx 0) idx MAXH; return idx; } int find(int k) { int idx h(k); while (used[idx]) { if (key[idx] k) return idx; // 找到 idx (idx 1) % MAXH; } return -1; // 不存在 } void insert(int k, int v) { int idx find(k); if (idx ! -1) { val[idx] v; return; } idx h(k); while (used[idx]) idx (idx 1) % MAXH; used[idx] true; key[idx] k; val[idx] v; }开放寻址法的最大陷阱删除元素很难。因为删除会让探测链断掉后面的元素就“消失”了。竞赛里如果遇到需要删除比如滑动窗口里的哈希计数别用开放寻址用拉链法或者unordered_map。另外注意MAXH一定要取质数不然取模分布会有规律性。我习惯取1e63、2e63这样的质数既保证容量又保证取模均匀。4.4 清空哈希表的三种姿势各有适用场景这绝对是一个经验点。你开一个全局哈希表多组数据时得清空怎么清memset(head, 0, sizeof(head))只适用于桶数量小的情况。桶有1e6个memset 也要 O(桶数)多组数据就慢。时间戳大法每个桶记录一个vis时间戳当前组数据标记为timestamp只有vis[桶] timestamp才当作有效桶。清空就是timestampO(1)。tot 0清空拉链表的 key 数组适用于拉链法tot 0之后旧的 key 虽然还残留在数组里但head已经全清或者全重置即“逻辑清空”。int vis[MOD], timestamp 0; bool check(int idx) { return vis[idx] timestamp; } void clear_all() { timestamp; } int main() { // 每组数据开始 timestamp; // 插入时 int idx k % MOD; if (vis[idx] ! timestamp) { vis[idx] timestamp; head[idx] 0; // 初始化这个桶 } ... }这个技巧在“多组数据 大桶”的场景里是保命技能。我见过学生用 memset 清空 1e6 的桶数组三组数据跑了 3 秒换成时间戳后 0.3 秒差距全在清空上。5. 字符串哈希CSP-S 字符串题的万能武器5.1 进制哈希的原理把一个字符串变成一个数字符串哈希的核心思想把字符串看成一个base进制的数比如abc看成a * base^2 b * base^1 c * base^0。这样每个字符串唯一对应一个整数理想情况下比较两个字符串是否相等就退化成比较两个整数是否相等。常用实现const int BASE 131; // 常用131、13331、137 const unsigned long long MOD (1ULL 64); // 自然溢出 unsigned long long h[N], p[N]; void init_hash(const string s) { int n s.size(); p[0] 1; for (int i 1; i n; i) { h[i] h[i-1] * BASE (unsigned long long)s[i-1]; p[i] p[i-1] * BASE; } } // 查询区间 [l, r] 的哈希值下标从1开始 unsigned long long get_hash(int l, int r) { return h[r] - h[l-1] * p[r-l1]; }这里的BASE先解释一下。为什么取 131因为 131 是个质数且足够大能尽量让不同的字符串对应不同的哈希值。“进制”类比成“数字表示”——就像十进制里 123 不可能等于 124 一样在 base 进制里只要 base 足够大且不产生进位冲突不同的字符串就会对应不同的数。Base 取太小比如 2字符串ab和ba可能碰撞取质数可以进一步减少碰撞概率。unsigned long long溢出自动取模2^64这是竞赛里最常用的做法因为 C 无符号溢出是定义好的行为不需要手动取模速度最快。5.2 区间哈希为什么要乘 p[r-l1]——这一步推导很重要很多学生把公式背下来但不理解。我拆开讲。设字符串s s_1 s_2 ... s_n前缀哈希定义是h[i] (s_1 * base^(i-1) s_2 * base^(i-2) ... s_i * base^0) mod M要求区间[l, r]的哈希相当于要单独计算s_l * base^(r-l) ... s_r * base^0。前缀h[r]里包含的是s_1到s_r的完整信息前缀h[l-1]里包含的是s_1到s_{l-1}的信息但它的权值基准和h[r]不一致。h[l-1]的最后一个字符s_{l-1}在h[r]里的权值是base^(r-(l-1)) base^(r-l1)所以要把h[l-1]整体“抬高”到对应位置即乘以p[r-l1]然后做差get_hash(l, r) h[r] - h[l-1] * base^(r-l1)生活类比十进制的数字12345想取中间三位234就是12345 - 12 * 1000 345 - 100 245不对本质是2345 - 2*1000 345再算12345去掉前两位得到3452345 - 2*1000 345刚好。base进制的p[r-l1]就是那个“1000”起到权重对齐的作用。5.3 双哈希 vs 自然溢出怎么选unsigned long long自然溢出虽然快但有被“卡碰撞”的风险。原理是 base 进制在2^64空间里虽然碰撞概率极低约n^2 / 2^64但出题人如果专门构造依然可能制造出两个不同字符串但哈希值相同的“哈希碰撞”。双哈希的做法用两组不同的 base 和 mod通常一组BASE131, MOD1e97另一组BASE13331, MOD1e99两个哈希值都相等才算字符串相等。碰撞概率降到两组的乘积级别基本不可能被卡。const int MOD1 1000000007, MOD2 1000000009; const int BASE1 131, BASE2 13331; long long h1[N], h2[N], p1[N], p2[N]; void init_hash(const string s) { int n s.size(); p1[0] p2[0] 1; for (int i 1; i n; i) { h1[i] (h1[i-1] * BASE1 s[i-1]) % MOD1; h2[i] (h2[i-1] * BASE2 s[i-1]) % MOD2; p1[i] p1[i-1] * BASE1 % MOD1; p2[i] p2[i-1] * BASE2 % MOD2; } } pairlong long, long long get_hash(int l, int r) { long long v1 (h1[r] - h1[l-1] * p1[r-l1] % MOD1 MOD1) % MOD1; long long v2 (h2[r] - h2[l-1] * p2[r-l1] % MOD2 MOD2) % MOD2; return {v1, v2}; }我个人的竞赛习惯常规题目用自然溢出因为快遇到explicit hack或者大字符串题比如字符串长度和数量都到2e5以上果断双哈希。多出来的一个%运算常数不大但保险系数提升几个量级。5.4 字符串哈希的经典战场回文、LCP、子串比较字符串哈希在竞赛题里最经典的用法有三类第一类最长回文子串的判定。判断一个区间[l,r]是否为回文只需比较哈希(正向[l,r])和哈希(反向[l,r])是否相等。正向哈希直接计算反向哈希可以预处理反向字符串的哈希再换算。第二类两个字符串任意子串是否相等。把两个字符串分别哈希O(1)得到任意子串哈希比较即可。这是后缀数组/后缀自动机很多题目的替代方案虽然功能不如 SA 全面但写起来简单太多。第三类二分字符串哈希解决“最长公共前缀”类问题。两个字符串比较字典序大小时可以先二分出第一个不同的位置然后比较该位置的字符。用哈希 二分复杂度从O(n)降到O(log n)。int lcp_hash(int i, int j, int len) { // 二分找第一个不同位置 int l 0, r len, ans 0; while (l r) { int mid (l r) 1; if (get_hash(1, i, imid-1) get_hash(2, j, jmid-1)) { ans mid; l mid 1; } else { r mid - 1; } } return ans; }这类题目在 CSP-S 里出现频率不低字符串哈希几乎是一种“带在身上的保险”比 KMP 灵活得多。6. 哈希表在CSP-S里的四个高频战场6.1 状态判重搜索题的隐形优化记忆化搜索里如果状态不是简单的几维数组能表示而是vectorint或mapint,int这种复合结构直接哈希判重比开高维数组省空间。典型题一个状态由多个值组成比如(x, y, mask)其中mask是 0-15 的位掩码总状态数可能到1e6。用unordered_maplong long, int存状态对应答案比开vis[16][16][116]省内存且更灵活。一个压状态的技巧把多个值直接拼成一个 long long减少哈希开销。比如(x, y, mask)拼成x * 100 y * 10000 mask只要保证不溢出。拼成一个数后unordered_map和手写哈希的查找都更快。6.2 众数与计数统计题的本命工具统计一个数组里出现次数最多的值unordered_mapint,int一行搞定unordered_mapint, int cnt; int maxv 0; for (int i 1; i n; i) { cnt[a[i]]; maxv max(maxv, cnt[a[i]]); }看起来简单但有个坑如果键的范围是[-10^9, 10^9]负数取模要小心。unordered_map对负数键没有问题但手写哈希时k % MOD可能为负务必加上偏移。另一个坑count 和 find 别混用。unordered_map的operator[]在键不存在时会自动插入默认值导致你本来只想查个存在性却凭空多出n个元素内存和时间都崩。查存在性用它返回迭代器的方式auto it mp.find(key); if (it ! mp.end()) { /* 存在 */ } else { /* 不存在 */ }6.3 坐标压缩与离散化哈希表接替排序离散化有两种写法传统的是sort unique lower_bound但遇到动态插入或多次查询时用哈希表更好用unordered_mapint, int mp; int get_id(int x) { static int cnt 0; auto it mp.find(x); if (it ! mp.end()) return it-second; return mp[x] cnt; }这种“动态离散化”在合并区间、离线算法的预处理阶段非常实用。你把n个坐标动态编号后续的树状数组、线段树都以编号做下标就不需要先排序再二分那么繁琐。对比一下如果只需要一次性离散化然后不做修改sort unique更快如果需要在线处理不知道后面会出现什么键哈希表的动态编号就是最优解。6.4 树和图论题里的哈希映射图论的“重边合并”“双连通分量合并”“虚树建图”这些场景经常需要对pairint,int做映射。C 标准库不直接支持pair的哈希但可以自己写struct pair_hash { size_t operator()(const pairint,int p) const { return (long long)p.first * 1000003 p.second; } }; unordered_mappairint,int, int, pair_hash mp;这个1000003是个接近1e6的质数乘上以后再加法能有效把pair的两个维度“搅和”进一个大整数里。如果两个键的first数量级是1e51000003足够让first和second不相互覆盖。我的经验是对pair哈希别用first ^ second这种简单的异或。因为(2,3)和(3,2)异或结果相同直接冲突。用乘法 加法混合要好得多。7. 哈希被卡、写挂、变慢的排错清单7.1 代码看起来没问题但答案错——先查哈希冲突哈希冲突的外在表现大多数用例正确个别大数据点 WA小数据全对。这是最典型的哈希冲突特征。排查步骤是不是unsigned long long自然溢出被卡换双哈希试试。是不是BASE取得太小换成 137 或 13331。是不是取模方式有误(h1[l-1] * p1[r-l1]) % MOD1必须做不能先减后模会产生负数。是不是字符串下标搞混了字符串哈希的h[0]是空串哈希写字串时务必从下标 1 开始。7.2 时间无限接近超时——先查哈希表常数“TLE但不超太多”的场景优先级最高的优化方向unordered_map换成手写哈希表通常能提速 3 倍以上。字符串哈希里手写while循环代替for substr。substr每次构造临时字符串是 O(len) 且带内存分配绝对不能用。能拼long long就不拆开存。比如状态是(x, y, z)尽量拼成一个数存哈希一次比哈希三次快。预先reserve键的数量级避免扩容的 rehash 开销。另外提一句大量使用unordered_map时开 O2 优化是必须的。CSP-S 的评测环境默认开 O2本地调试如果不开unordered_map可能慢到怀疑人生但这不代表评测环境也会超时。7.3 负数取模踩坑实录以下代码片段我见过至少十次int idx key % MOD; // key -5, MOD 7 时结果为 -5访问 head[-5]C 的%对负数返回负值和数学意义上的模不同。修复方式int idx ((key % MOD) MOD) % MOD;或者写成int idx key % MOD; if (idx 0) idx MOD;后者更快因为避免了一次额外的%。在多组数据、大查询量的时候后者能省几千万次取模运算。7.4 多组数据时的清空陷阱哈希表在多组数据里最容易翻车的就是残留数据。你上一组数据插入的键在下一组数据里可能“幽灵般存在”。三个必查的点tot有没有归零拉链法里tot不清零会导致数组越界或复用旧节点。head有没有清零memset(head, 0, sizeof(head))全清没问题但大数组下慢时间戳法记得每组timestamp。开放寻址法的used数组有没有全清memset(used, 0, sizeof(used))可以但如果数组很大且组数很多考虑用“版本号”技巧避免每次都 O(数组大小)。7.5 什么时候别用哈希选别的算法哈希不是万能的。遇到以下情况果断换工具要求统计有序信息排名、前驱后继、第k小——用平衡树或树状数组。要求字典序比较字符串且字符串数量极大——后缀数组比哈希更稳因为哈希 二分虽然能快速比较但遇到全相同的字符串需要反复二分极端情况下性能下降。键本身有结构比如一个数组、一棵树的状态——直接哈希整个结构开销大优先考虑用vectorint的字典序方案或编码成字符串再哈希。数据范围小n ≤ 1000——直接开数组别用哈希表。数组随机访问比哈希表快一个量级还不用处理冲突。7.6 一个实测对比手写哈希 vs unordered_map vs map我做了一个简单测试n 1e6个随机数插入并查询1e6次耗时对比如下实现耗时内存mapint,int约 3.1s约 60MBunordered_mapint,int约 0.9s约 50MB手写拉链哈希MOD 1e63约 0.25s约 40MB注意这只是单组数据的表现。多组数据下手写哈希 时间戳清空的优势还会进一步扩大。这也是为什么说哈希表是CSP-S的“默认选项”但默认不意味着随便用。会用unordered_map是第一步会手写、会防卡、会清空是第二步。前一步让你能写对后一步让你能过数据。8. 字符串哈希在2024年CSP-S的考法复盘与2025年备赛方向8.1 从真题看哈希表的“考频”与“考法”CSP-S 近几年的真题里哈希表很少单独出一道“哈希题”但作为底层工具出现频率极高。比如2023年提高组初赛的“字符匹配”类选择题考察字符串哈希的基本公式推导。2024年网络上热议的“CSP-S 2024 决斗”相关题目讨论中哈希表常作为判重、去重的辅助数据结构出现。为什么会这样因为信息学奥赛的考点设计逻辑是“考算法思维不考工具本身”。哈希表作为工具它的意义是让你在解决本质问题时少写模拟、多留时间去优化核心环节。2025年备赛你要重点练的是在一道综合题里主动识别“哪里可以用哈希”。看到一个题先想这个题是“判重、计数、映射、匹配”哪一类再决定用哪种哈希方案。这个决策能力比单纯背模板重要得多。8.2 哈希表组合技哈希 二分、哈希 DP、哈希 数据结构哈希表很少单独出现它通常和别的算法组合成“组合技”。哈希 二分最典型的是“最长公共子串长度”的问题。两个字符串二分一个长度mid用哈希判断是否存在长度为mid的公共子串。把第一个字符串的所有长度为mid的子串哈希存入unordered_set再扫第二个字符串的对应长度子串查存在性。// 二分 mid for (int i 1; i mid - 1 n; i) { st.insert(get_hash(1, i, i mid - 1)); } bool ok false; for (int i 1; i mid - 1 m; i) { if (st.count(get_hash(2, i, i mid - 1))) { ok true; break; } }哈希 DP经典的“字符串不同子串个数”可以用后缀自动机SAM但也可以用哈希 二分 DP 实现暴力枚举。尤其当n ≤ 5000时暴力枚举所有子串 setunsigned long long去重代码量极小思路清晰。setunsigned long long seen; for (int len 1; len n; len) { for (int i 1; i len - 1 n; i) { seen.insert(get_hash(i, i len - 1)); } } int ans seen.size();哈希 数据结构比如“给一棵树问两个子树是否形态相同”可以把子树结构哈希成一个值比如子树哈希 左子树哈希 * BASE 右子树哈希然后用mapull, int记录不同形态的数量。哈希在这里简化了复杂结构的比较问题。8.3 哈希的“随机化防守”用随机模数防构造数据CSP-S 的题目不会恶意构造哈希碰撞数据但线上赛的 Hack 模式里有人会。防守方法除了双哈希还有“运行期随机模数”const int MOD 1000000007; // 运行期随机选取本组的 base mt19937 rng(chrono::steady_clock::now().time_since_epoch().count()); int BASE uniform_int_distributionint(131, 13331)(rng);这样每组测试的 base 不同Hack 者没法提前构造针对你的数据的碰撞。注意如果题目要求两次运行输出必须一致随机 base 可能导致不同运行结果不同竞赛一般不采用。做题时只有“提交一次”的机会随机 base 是安全的但在本地调试时要固定 base否则对比结果可能莫名其妙。8.4 哈希边界情况汇总下标、溢出、空串哈希写多了最容易出错的边界情况我列个清单空串哈希h[0] 0get_hash(1, 0)这种区间不合法要提前判断。区间长度为0get_hash(l, r)当l r时返回什么建议返回 0。乘法溢出h[l-1] * p[r-l1]用unsigned long long自然溢出没问题但用手动%时要取模后再乘避免long long溢出。字符串下标越界用 1-indexed 还是 0-indexed 要统一。我习惯 1-indexedh[i]表示前i个字符的哈希。9. 我的实操心得哈希表题目从读题到AC的稳定四步带学生刷了上百道哈希相关题目后我总结了一套稳定的做题流程第一步识别类型。看到题目先问自己这是判重、计数、映射、匹配中的哪一类可能同时是两类比如“两个字符串有多少相同子串”既是映射又是匹配。第二步估算规模。n是1e5还是1e6键值范围多大有没有负数能不能拼成long long这些都决定选哪个方案。第三步选择工具。规模小且简单——map或数组规模大且只需要计数——unordered_map reserve规模大且对时间敏感——手写拉链哈希涉及字符串子串比较——字符串哈希自然溢出或双哈希。第四步防御性编码。写上防冲突的哈希函数加上负数的idx调整预留reserve多组数据用时间戳清空然后才提交。这个流程听起来简单但执行到位可以避免 90% 的哈希翻车。很多学生栽在第二步——连规模都没算清就开写写完了才发现unordered_map不够快重写手写哈希白白浪费二十分钟。10. 最后分享一个实战技巧哈希表的“调试神器”最后单独说一个我在调试哈希表时常用的技巧溢出检测法。当你怀疑某个unordered_map或手写哈希挂了但不确定是冲突还是逻辑错误时就在两个不同实现之间交叉验证。比如先用map跑一遍小数据再用unordered_map跑同一份数据对比结果。如果n ≤ 1000时两者结果一致n变大后有差异那基本锁定是冲突。再比如字符串哈希可以用一个暴力O(n^2)的子串比较函数来“对拍”哈希的结果bool brute_equal(int l1, int r1, int l2, int r2) { if (r1 - l1 ! r2 - l2) return false; for (int i l1, j l2; i r1; i, j) { if (s[i-1] ! t[j-1]) return false; } return true; }小数据对拍几十组确认哈希和暴力完全一致后再去跑大数据。这种“小数据暴力 大数据哈希”的组合是我个人写哈希相关题目最爱的调试方式基本能定位 99% 的哈希错误。哈希表在 CSP-S 里是个“你总以为自己会”的知识点但真正拉开差距的恰恰是那些默认你会、实际你没吃透的底层细节。希望这篇内容能帮你把哈希表的原理、手写模板、字符串哈希公式和防卡技巧一次吃透2025年赛场上不再因哈希丢分。

相关新闻

pytorch深度学习实践(刘二大人)课堂代码作业——线性模型

pytorch深度学习实践(刘二大人)课堂代码作业——线性模型

一、课堂代码np.arange( ):用于创建一个等间隔的数组(类似于 Python 中的 range() 函数),其参数包括起始值、终止值和步长。np.arange() 函数生成的数组不包括终止值本身,即从起始值开始,依次加上步长&…

2026/10/10 8:14:47 阅读更多 →
计算机毕业设计之jsp基于Java的旅游网站的设计与实现

计算机毕业设计之jsp基于Java的旅游网站的设计与实现

系统根据现有的管理模块进行开发和扩展,采用面向对象的开发的思想和结构化的开发方法对旅游管理的现状进行系统调查。采用结构化的分析设计,该方法要求结合一定的图表,在模块化的基础上进行系统的开发工作。在设计中采用“自下而上”的思想&a…

2026/10/10 8:14:46 阅读更多 →
运维相关安装包下载地址统计(持续更新)

运维相关安装包下载地址统计(持续更新)

通用软件: jdk: https://www.oracle.com/java/technologies/downloads/#java17 (可更改最后面的版本号来下载自己所需要的版本) docker: https://download.docker.com/linux/centos/7/ , https://download.docker.com/linux/static/stable/ d…

2026/10/10 8:14:46 阅读更多 →

最新新闻

C语言进阶实战:从环境配置到项目开发的完整指南

C语言进阶实战:从环境配置到项目开发的完整指南

这篇《C语言学习6》写的时候,我心里挺有感触的。前面五篇把基本语法、分支循环、数组函数都过了一遍,但真正从“看懂”变成“会写”,靠的还是这段时间反复踩坑、反复调试的积累。这篇不打算再堆语法知识点,而是把这一阶段让我印象…

2026/10/10 9:37:44 阅读更多 →
超市进销存管理系统源码实战:从跑通到生产级避坑指南

超市进销存管理系统源码实战:从跑通到生产级避坑指南

简介:这份超市进销存管理系统源码面向Java初学者与中小零售项目开发者,帮助理解采购、销售、库存等核心业务在代码层面的落地方式。系统涵盖登录验证、销售订单增删改查、商品统计报表等模块,源码中可见销售单、进货单、退货单及入库查询等业…

2026/10/10 9:37:44 阅读更多 →
数据结构C语言课设完整实现:从Makefile到可运行工程

数据结构C语言课设完整实现:从Makefile到可运行工程

简介:这是一份面向计算机专业学生与C语言学习者的数据结构课程设计完整源码包,围绕单链表、栈、队列、二叉树与图五种核心结构展开,通过多级菜单串联各模块的基本操作与典型应用,适合课程设计参考、期末复习与算法入门练手。压缩包…

2026/10/10 9:37:44 阅读更多 →
Node.js Worker线程自动重启:从无声崩溃到生产级自愈方案

Node.js Worker线程自动重启:从无声崩溃到生产级自愈方案

去年处理一个图片缩略图服务时,我遇到了一个很诡异的事:任务队列突然卡死,积压了几万条消息,主进程的CPU和内存却完全正常,监控面板上唯一的异常是——某个worker线程不见了。最后排查发现,worker里一段不起…

2026/10/10 9:37:43 阅读更多 →
SpringBoot医药知识推荐平台毕设实战:从推荐算法到系统部署

SpringBoot医药知识推荐平台毕设实战:从推荐算法到系统部署

每年毕业季,计算机专业的毕设选题里,“SpringBoot XX管理系统”绝对是出现频率最高的组合。但如果你选的题目是“医药知识推荐平台”,光会写增删改查那一套还真不够——推荐功能才是这个项目的灵魂。我最近正好完整复盘了一个编号为13126的S…

2026/10/10 9:37:43 阅读更多 →
出海实战避坑指南:用好Ask Me专家资源,少走弯路

出海实战避坑指南:用好Ask Me专家资源,少走弯路

出海这件事,这几年真的被太多人问过了。见得多了之后我发现一个规律:大多数出海踩坑的团队,不是不够拼,而是“问错了人”或者“没问到点子上”。所以当看到“出海有问题,尽管Ask Me!2026出海实战专家已就位…

2026/10/10 9:36:42 阅读更多 →

日新闻

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

1. 从“卫星轨道分类”这个标题说起:为什么值得花时间搞懂第一次接触“卫星轨道分类”这个概念,很多人会觉得它离自己很远——不就是天上的星星怎么转吗?但如果你正在做航天任务规划、遥感数据接收、星座设计,甚至只是准备一场航天…

2026/10/10 0:00:39 阅读更多 →
Spring AOP 核心原理与实战:从概念到日志切面落地

Spring AOP 核心原理与实战:从概念到日志切面落地

1. 从一个真实痛点说起:为什么你的代码里到处都是重复逻辑刚入行那会儿,我写过一个用户管理模块,注册、登录、改密码、注销四个接口。每个接口里都塞了几乎一样的日志打印、参数校验、事务开启和提交。当时觉得没什么,能跑就行。直…

2026/10/10 0:00:40 阅读更多 →
Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

简介:这是一套面向计算机相关专业学生与项目实战学习者的Python数据采集与分析可视化完整项目,以Boss直聘岗位数据为对象,适合用作毕业设计、课程设计或期末大作业。资源包共38个文件,约246KB,以13个py源码文件为核心&…

2026/10/10 0:00:40 阅读更多 →

周新闻

KT148A语音芯片外挂8002D功放的工程实践指南

KT148A语音芯片外挂8002D功放的工程实践指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/8 15:26:32 阅读更多 →
LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/10 1:36:08 阅读更多 →
ARM架构深度解析:从RISC设计理念到交叉编译实战

ARM架构深度解析:从RISC设计理念到交叉编译实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 10:11:06 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/10 5:23:50 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 21:32:20 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 6:17:20 阅读更多 →