算法复杂度怎么比较

在远程协作开发中，团队成员常遇到这样的问题：两个功能差不多的算法，到底该用哪个？有人主张代码简洁，有人坚持运行快。这时候，真正能“说话算数”的，往往是算法复杂度。

比如你们组正在做一个在线文档协同编辑功能，后端需要频繁处理用户操作的合并逻辑。小李写了个嵌套循环的实现，测试数据少时没问题；小王用了哈希表优化，代码多几行。上线前一测大数据量，小李的版本卡得动不了——这就是复杂度差异带来的真实影响。

算法复杂度通常用大O表示法来描述，它关注的是输入规模变大时，执行时间或空间增长的趋势。比如 O(n) 表示时间随数据量线性增长，O(n²) 就是平方级增长。

举个例子，你要遍历一个长度为 n 的数组查找某个值：

for (int i = 0; i < n; i++) {
    if (arr[i] == target) return i;
}

这是 O(n) 的时间复杂度。而如果写了两层循环去比较每一对元素：

for (int i = 0; i < n; i++) {
    for (int j = 0; j < n; j++) {
        if (arr[i] == arr[j]) count++;
    }
}

这就成了 O(n²)，当 n 从100变成1万，耗时可能从毫秒级跳到几秒。

O(1) 是最优的，无论数据多少都只花固定时间，比如访问数组下标。
O(log n) 常见于二分查找，数据翻倍也只多花一点点时间。
O(n) 是普通遍历。
O(n log n) 多见于高效排序，如快排、归并。
O(n²) 或更高，就要警惕了，特别是处理列表、树、图这类结构时容易踩坑。

远程开发中，很多人本地测几十条数据没问题就提交了，结果别人一跑上千条直接超时。这时候回过头看复杂度，往往发现是 O(n²) 撞上了大数据。

除了时间，空间复杂度也得看。比如递归太深可能导致栈溢出，或者缓存全量中间结果导致内存飙升。在云服务按资源计费的今天，空间不省，成本就上去了。

比如有个同步任务，你把所有变更记录都存内存里再统一处理，看着逻辑清楚，但项目越大越吃内存。换成流式处理，边读边处理，空间复杂度从 O(n) 降到 O(1)，服务器压力立马减轻。

在 Git 提交或 Code Review 中，看到涉及循环、递归、嵌套结构的代码，不妨多问一句：这个最坏情况会怎么样？能不能从 O(n²) 降到 O(n)？有没有现成的数据结构能借力？

有时候改一行代码，换一个思路，复杂度就能降一个级别。比如把查找从数组改成哈希表，时间复杂度就从 O(n) 变 O(1)。这种优化在远程协作中特别值得提出来讨论，不是炫技，而是为系统长期稳定考虑。

算法复杂度不是理论考试题，它是写在每一行代码背后的效率账。尤其在分布式的协作场景下，谁的模块拖慢整体，日志一查就知道。提前把复杂度理清楚，省下的不只是时间，还有半夜被报警叫醒的烦恼。

算法复杂度怎么比较：远程协作中的效率选择