算法复杂度重要吗？真实场景告诉你何时该关注

你有没有遇到过这种情况：写了个小程序，本地跑得飞快，结果一上线，数据量刚上万，页面就卡得像老牛拉车？可能你没想太多，只觉得‘代码还能优化’。其实问题很可能出在算法复杂度上。

简单说，它就是衡量一段代码‘随着输入变大，执行时间或占用内存增长有多快’的指标。比如你有个数组，里面有10个数，查找一个值很快；但如果数组有100万个数，你的查找方式是不是还那么快，这就看出算法复杂度的差别了。

常见的有时间复杂度和空间复杂度。我们最常关心的是时间复杂度，用大O表示法，比如 O(1)、O(n)、O(n²) 这些。

想象你在做个小工具，要对比两个列表里的重复项。图省事，你用了两层 for 循环：

for (int i = 0; i < n; i++) {
    for (int j = 0; j < n; j++) {
        if (list1[i] == list2[j]) {
            // 找到了
        }
    }
}

看起来没问题，n 是10的时候，循环100次，眨眼完成。可当 n 变成1万，循环次数就是1亿次——这时候程序卡住就不奇怪了。这就是 O(n²) 的代价。

换成哈希表，把一个列表先存进去，再遍历另一个列表查，时间复杂度降到 O(n)，速度立马不一样。

当然，也不是每个函数都要抠到 O(log n)。如果你只是处理几百条数据的小脚本，用冒泡排序也无所谓，没人会察觉。但在一些关键路径上，比如接口响应、批量任务、推荐系统，复杂度直接影响用户体验甚至服务器成本。

举个生活化的例子：你去超市买东西，收银员手忙脚乱一个个扫码，慢是慢点，但能接受。可如果她每扫一个，都要回头翻一遍整个货架确认有没有重复，那你还不得急死？这就像在不该用嵌套循环的地方用了嵌套循环。

当你发现程序在小数据下流畅，数据一多就崩，或者同事说‘这逻辑得重构’，八成就该看看复杂度了。尤其是做后端开发、数据分析、写爬虫合并数据，这些地方坑最多。

掌握常见结构的复杂度，心里就有谱了。比如：

这不是让你背公式，而是培养一种直觉：这个操作会不会随着数据变大而越来越慢？

算法复杂度不是玄学，也不是只有大厂面试才用得上。它是帮你写出更健壮代码的实用工具。懂一点，能在关键时刻少踩坑，尤其是在项目从‘能用’走向‘好用’的过程中。

下次写循环前，花十秒钟想想：我这层再套一层，数据翻十倍还能扛住吗？这个问题，比背一百道题更有用。

算法复杂度重要吗？别被它吓到，但也不能忽视