读懂数据范围再写代码：一道两数之和讲透算法复杂度选型

有一次评审组里同学的算法练习，题目是那道人人都见过的“两数之和”——给定数组和一个目标值，找出两个数使它们的和等于目标值。他写得很认真，但代码是双层循环暴力嵌套。我问他：“你注意到数据范围了吗？”他愣了一下说：“看到了，n 最大 10^5，但不知道怎么用它。”后来我又把题目原封不动丢给他，唯一改动是明确告诉他“n 是 10^5”，他几分钟就交了一版哈希的做法。

这件事让我印象很深，因为很多人缺的不是解题能力，而是一个最基础的习惯：根据已知数据范围选择算法。数据范围是题目里最便宜的线索，它直接告诉你能承受多大的时间复杂度，甚至能在你动手写代码之前帮你淘汰掉一半错误方案。这篇文章我想把这套思考方式完整拆开，从一道题讲起，再讲怎么推广到工程开发里真正用起来。

1. 先从一道“老熟人”题目说起：数据范围会替你做决策

1.1 同一个需求，三种数据范围，三种解法

还是“两数之和”这道题，但给三个不同的数据范围版本：

• 版本 A：n ≤ 1000。这时候最简单的就是双重循环，直接枚举每一对数字，复杂度 O(n²)，1000 的平方也就 100 万次操作，任何环境下都跑得飞起。你非要用哈希表当然可以，但没必要，因为暴力写起来最不容易出错。
• 版本 B：n ≤ 10^5。此时双重循环是 10^10 次操作，已经严重超时。你需要在“排序 + 双指针”的 O(n log n) 和“哈希表”的 O(n) 之间做选择。如果题目要求返回两个数的下标，排序会破坏原有位置，得额外记录原坐标；哈希一遍扫描则是更省心也更稳的方案。
• 版本 C：n 高达 10^7，但每个数字的取值范围非常小，比如都在 [0, 100] 内。这时候你甚至不需要排序和哈希，开一个长度为 101 的频次数组扫一遍就能同时完成统计和配对，复杂度直接降到 O(n)。

同一个需求，数据范围一变，代码结构完全不一样。这就是标题想表达的核心理念：算法不是越高级越好，而是“刚好处在该数据范围允许的复杂度区间内”最好。

1.2 数据范围到底在替我们决策什么

数据范围做出的决策，本质上是两个约束的交集：时间约束和空间约束。

先说时间。一般场合下，我们保守估算一个程序每秒能执行大约 10^8 次简单操作，实际还要受编译器优化、语言解释器性能、输入输出开销影响。有了这个基准，就可以粗略推导：

• n ≤ 10^3，O(n²) 是安全的，因为最多 10^6 次操作；
• n ≤ 10^5，O(n log n) 是安全边界，因为 n log n 大概只有 1.7×10^6 次比较；
• n ≤ 10^6，就强烈建议 O(n) 了，如果你想用 O(n log n) 也不是不行，但常数得控制得很好；
• n 到 10^7 甚至更大，基本只能接受 O(n) 且常数极小，或是 O(log n)、O(√n) 这类方案。

再说空间。遇到面试或工程场景，我们通常会关注内存上限，比如 256MB 或 512MB。粗略算一下，256MB 大约能存放 6.7×10^7 个 int，为了保险，一般按 5×10^7 个 int 来做预估。如果你发现 dp 数组要开到 n² 的大小而 n 是 10^5，那就等于直接宣告了这个方案不可行，得换成滚动数组、稀疏表或者离线算法。

这两个换算都是非常机械的动作，但它们比任何解题技巧都更先发生。很多人以为算法难在“想不出思路”，其实一大部分难在“思路太多，没靠数据范围提前筛掉不合适的”。

1.3 先把“会不会”变成“选哪个”

我后来带人练题时，反复强调一个三步循环：

1. 读题后先圈出所有数字限制，包括 n、m、值域范围、是否有有序性提示、是否多组数据且有总量上限。
2. 立刻做一次时间和空间的粗算，在草稿纸上写“目标复杂度 <= O(n log n)”或“最多能开 5×10^7 的数组”这类结论。
3. 把候选算法列出来，挑一个复杂度刚好在边界内、实现最简单、边界条件最容易控制的写。

这个习惯最大的好处，是把“我会不会这道题”的焦虑，转化成“我应该选哪个方案”的决策。人的思维在决策模式里比在回忆模式里要可靠得多。

2. 数据范围与复杂度怎么换算：一张表看懂该写多快

2.1 输入规模分档与可接受复杂度对照

下面这张表是我平时用得最多的参考，直接抄作业即可：

为什么 20 这个数很关键？因为 2^20 约等于 100 万，状态压缩枚举是可行的；但 n=30 时 2^30 就是 10 亿，直接爆了。所以很多涉及“子集选择”的题目，数据范围卡在 n≤20，就是在明确暗示你用状态压缩 DP。

同样，n≤10^5 是最常见的一道分水岭。很多人在这个规模上栽跟头，就是因为习惯了 O(n²) 的思路，一到 10^5 就超时。记住一句话：看到 10^5，第一反应应该是“排序/二分/哈希”，而不是“暴力”。

2.2 时间限制不是玄学：操作数估算

判断一个方案能不能过时间限制，我推荐一个笨但有效的办法：把最坏情况的操作次数算出来。比如两层循环 i 和 j 都跑 n，那么操作次数大约是 n²；一个排序大概有 n log n 次比较；一次哈希表插入删除约等于常数次操作。

拿 n=10^5 来举例，双层循环是 10^10，远超 10^8 的安全线；而排序的 1.7×10^6 次比较则非常轻松。这里有一个需要额外注意的地方：理论复杂度相同，实际耗时也可能差出几倍。举个真实感受，同样是“查找元素是否存在”，哈希表 O(1) 的平均复杂度，在数据分布很差、冲突严重时，可能退化到接近 O(n)，性能崩得比想象中快得多。所以估算时，还要给常数因子留余量。

另外，不同的语言对复杂度上限的宽容度完全不同。同样的 10^7 次操作，在编译型语言里或许能稳稳通过，在解释型脚本语言里就可能非常紧张。如果你工作中主要用脚本语言，就要把“可承受复杂度的安全线”再调低一个量级。

2.3 空间限制也要算：别让算法“超内存”

空间这块，我见过太多次“代码逻辑正确但提交直接内存超限”的情况。最常见的错误模型是：开了一个 n×n 的二维数组来做动态规划，而 n 是 10^5，空间直接是 10^10 个 int，这显然不可行。

但在实际工程里，我们往往可以靠观察数据范围来规避这种错误。如果状态转移只用到了前一行，就果断改成两行滚动数组；如果矩阵很大但很稀疏，就用哈希表或者邻接表；如果值域不大，用普通数组做桶，而不是用重量级的映射结构。

给大家一个实用的口头禅：“先算占用，再写代码。”一个 int 是 4 字节，一个 long 是 8 字节，1 千万个 int 大约 40MB。你用这个比例去对照题目给的内存上限，三秒钟就能判断一个方案是否靠谱。

3. 别只盯着“N”：还有三类数据范围信息值得读

3.1 值域大小决定“桶”能不能用

很多人的“读数据范围”，只读了数据个数 N，却漏了数值本身的范围。这里的“值域”才往往决定了一些更取巧的算法能不能用。

举一个非常接地气的场景：要给 n=10^5 个整数做排序，但题目保证每个数都在 [0, 100] 之间。这时候计数排序是无敌的：开一个 101 大小的数组，扫一遍源数据统计频次，再按频次输出，复杂度是 O(n)，而且实现比快排简单得多。可如果同一个题目把值域改成 [-10^9, 10^9]，计数排序和桶排序直接失效，因为你没法开一个长度 20 亿的数组，必须回到快排或堆排序。

所以在草稿纸上圈数据范围时，一定要把“每个数的最小值”和“最大值”单独圈出来。值域小，很可能意味着可以用频次数组、桶、位图这类“以值域换时间”的玩法。

3.2 正负性带来下标映射问题

负数这个问题很基础，但非常容易被忽略。比如你要统计一个数组中“某个值出现多少次”，如果值域包含负数，你直接用 cnt[value]++ 是行不通的，因为下标不能是负数。

解法有两种。第一种是加偏移量：如果题目保证值域在 [-100, 100]，那就开一个 201 大小的数组，实际下标取 value + 100。第二种是直接用哈希表，以值为 key，频次为 value。

这里有个新手常犯的错误：偏移量不是看绝对值最大值，而是要看真实的最小值。比如值域范围是 [-100, 200]，最小值是 -100，那偏移量就是 100，数据映射到 [0, 300]。如果你只拿绝对值最大值 200 去当数组长度，就可能写错边界。读题时把 min 和 max 都圈出来，这种问题就能彻底避免。

3.3 有序性让算法白赚一个量级

有些题目会在数据范围描述里看似不经意地写一句“数组已按升序排序”或者“输入保证有序”。这句话简直是白送的信息，能极大简化算法。

举个例子，两数之和在无序数组里需要哈希表 O(n) 空间；但如果是有序数组，双指针从头尾往中间逼近，O(n) 时间、O(1) 空间就解决了，连哈希都不用开。同理，在有序数组里做查找可以直接二分，做去重可以相邻比较。

如果数据本身无序，而题目又允许你自行排序，你就得把排序的 O(n log n) 成本也确实计入总体预算。很多方案本身是 O(n)，结果你为了用双指针先排了个序，总体变成 O(n log n)，在 n 很大时反而吃亏。这个判断同样是靠数据范围做出来的。

3.4 字符串、矩阵、图：数据范围给的是“形态”

有些问题的数据范围不是“一个 N”，而是多个维度的组合。读题时要把这些组合都圈出来：

• 字符串题，如果写着“所有字符串总长度不超过 10^6”，那你建一棵字典树是安全的；如果总长度到 10^7，就得考虑压缩存储后缀自动机等更省空间的方案。
• 矩阵题，要关注 n×m 的乘积。n=10^3、m=10^3，那面积是 10^6，二维 DP 或者 DFS 都可以；如果 n=10^5、m=10^5，面积是 10^10，任何依赖完整矩阵遍历的思路都不成立，只能想数学解法或行/列压缩。
• 图论题，关注点数和边数。n≤10^5、m≤10^5，基本上 BFS、DFS、最短路都可以；n≤20，则可以启发式枚举所有点集。

所以数据范围给出的不只是“数字大小”，更是“数据形态”。形态决定了你应该进入哪种算法家族，这是在动笔之前就应该完成的判断。

4. 这种思维怎么迁移到工程开发里

4.1 业务日志和接口查询里的“数据范围”

你可能以为这套东西只在刷题时有用，其实工程里的数据范围思维更加值钱，只是换了个说法：它叫“容量评估”。

举几个真实工作中的例子：

• 业务日志去重。如果一天日志只有 100 万行，你完全可以在内存里放一个 HashSet 进行去重，简单直接；但如果一天日志有 10 亿行，内存立刻就不够用了，你需要布隆过滤器、分片哈希、或者外部排序归并。同样是“去重”需求，数据量级直接决定了方案选型。
• 前端表格搜索。10 万行数据在本地做 filter + map 毫秒级返回，根本不用设计索引；但如果数据量到千万级，就必须交给后端数据库，配合索引甚至搜索引擎来查。
• 报表查询。查某一天的数据明细，直接扫表没问题；查一整年的数据，就必须依赖预聚合表，否则无论怎么优化都会超时。

工程中最傻的坑，不是不会写代码，而是拿到需求不先问“数据量有多大、峰值有多高、时间窗口有多宽”，就直接按照教科书方案开工。这跟刷题时不读数据范围就写暴力循环，本质上是同一个问题。

4.2 一个文件求交集的例子：范围决定方案

我经常和同学聊一个自己遇见过的场景：两个文件里各存了一批用户 ID，求这两个集合的交集。文件 A 是 100MB，文件 B 是 10GB，内存限制 1GB。

这个规模下最优解很简单：把小的 100MB 文件加载进内存，建成哈希集合，然后流式读取大文件，每读一条就在哈希集合里查一下。复杂度是 O(大文件行数)，空间只跟文件 A 相关。

但如果你把“文件 A 100MB”改成“文件 A 也 10GB”，情况就变了。两个文件都超过内存，你只能把 ID 分段哈希到不同的小块文件里，再逐段做交集；或者借助外部排序归并。方案从“哈希 + 流式”直接升级为“分治 + 归并”。

这就是工程版的数据范围选择算法。每次做技术选型前，先把量级摆到桌面上，答案会自然浮现，而不是凭感觉拍脑袋。

5. 常见问题与排查技巧实录

5.1 五个高频踩坑场景

这些年看过的代码里，最常见的五个坑基本是固定的：

第一个坑：不看规模直接暴力。n=10^5 写 O(n²)，这属于没养成“先读数据范围”的习惯。

第二个坑：只读 N，不读值域。看到 n=10^5 就写哈希表，但实际上数值范围只有 [0,100]，用桶更简单也更快。反之，看到值域很大却强行用数组下标，直接段错误。

第三个坑：选了理论复杂度低但常数爆炸的方案。比如 n=10^5 用普通树形映射结构做统计，虽然 O(n log n) 理论上能过，但常数太大，跑起来比 O(n²) 还慢。这种情况应该用哈希表或者值域桶，把常数压下来。

第四个坑：低估排序成本。有些方案先排序再处理，排序确实多出 O(n log n)。n 不大时无所谓，但 n=10^7 时，多一个 log n 因子可能让总耗时从 0.5 秒变成 5 秒。

第五个坑：只在小数据上自测。小数据秒过，一上全量数据就超时或内存溢出，这种问题在考试和面试里都非常可惜，因为数据范围明明明明白白写着，提前用边界数据测一下就能发现。

5.2 问题速查与避坑建议

我个人还有一个压箱底的技巧：动手写算法前，在代码注释里先写上三行字，分别是 N = ?、值域 = ?、目标复杂度 = ?。这个做法相当于给自己立了一张合同。每写一段循环，就抬头看一眼目标复杂度，如果发现已经逼近甚至超过预算，立刻停下来换方案。用这三行注释，比事后调试要高效得多。

6. 结尾：多花 30 秒读数据范围，少熬几小时深夜 debug

我现在的习惯，拿到任何一个问题，第一件事永远是画三个圈：数据量 N、数值范围、特殊限制。然后心里快速算一遍时间和空间边界，再决定用哪一套算法。整套动作下来不过 30 秒，但足以避免绝大多数“算法选错”带来的返工。

这 30 秒换来的是清醒的决策。选错了算法，后面几小时都是在错误地基上修修补补；选对了算法，就算实现有点瑕疵，修起来也只是小打小闹。如果你也经常陷入“思路懂一堆，题目却总超时”的窘境，我建议你别急着加大刷题量，先试着把读数据范围变成解题的第一习惯，效果大概率比你想象中明显。