在日常开发中，经常会听到同事说某个算法“太慢了”或者“效率不够高”。但到底怎么才算慢？有没有一个标准来衡量？这时候就得靠算法效率评估公式来说话了。
时间复杂度：看得见的“快慢”
最常用的评估方式是时间复杂度，用大O符号表示。比如一个循环遍历数组的操作，执行次数和数组长度n成正比，我们就会说它的时间复杂度是 O(n)。如果嵌套两层循环，就变成 O(n²)，数据量一大，运行时间就明显拉长。
举个生活中的例子：你在整理书架，每本书都要和其他所有书比较一次，看看谁该放前面。如果有10本书，要比较近100次；书变成20本，比较次数直接跳到400次。这就是 O(n²) 的真实体验——东西一多，耗时指数级上升。
空间复杂度：内存占用也得算
除了运行时间，还得看内存开销。比如递归调用太深，系统栈会占用大量内存，可能直接导致程序崩溃。这种情况下，即使算法逻辑正确，实用性也会打折扣。空间复杂度同样是用 O 表示，像 O(1) 代表只用固定内存，O(n) 表示随输入规模线性增长。
常见效率公式对照
下面是一些常见的算法效率级别，从快到慢排列：
- O(1) —— 常数时间，比如数组按索引取值
- O(log n) —— 对数时间，典型的是二分查找
- O(n) —— 线性时间，遍历列表
- O(n log n) —— 快速排序、归并排序的平均情况
- O(n²) —— 冒泡排序、选择排序
- O(2^n) —— 指数级，比如暴力解斐波那契递归
代码里的效率差异
来看一个简单的对比：
// 查找数组中是否有目标值，O(n) 方法
function find(arr, target) {
for (let i = 0; i < arr.length; i++) {
if (arr[i] === target) return true;
}
return false;
}
// 如果数组有序，改用二分查找，O(log n)
binarySearch(arr, target) {
let left = 0, right = arr.length - 1;
while (left <= right) {
const mid = Math.floor((left + right) / 2);
if (arr[mid] === target) return true;
else if (arr[mid] < target) left = mid + 1;
else right = mid - 1;
}
return false;
}数据量小的时候差别不明显，但当数组有上万项，二分查找可能只要几十步，而线性查找得走完上万次。
别光看理论，结合场景判断
有时候 O(n²) 的算法反而更实用。比如插入排序在小数据集上比快速排序还快，因为它逻辑简单，常数项低。这说明评估不能只看公式，还得结合实际数据规模和使用环境。
就像修路，大城市需要立交桥（复杂高效算法），小村子一条直道就够了（简单够用就行）。算法效率评估公式不是死标准，而是帮我们在设计时做出更合理的权衡。