你有没有试过在深夜赶工时，一边写代码一边等程序跑结果，心里默默数着秒？就像煮泡面，三分钟和五分钟的区别，可能就是饿晕前还是饿晕后能吃上一口。
为什么效率不是“快就行”？
很多人觉得程序跑得快就是好，但现实往往更复杂。比如你写的程序处理10条数据很快，可一旦换成1万条，电脑风扇开始咆哮，屏幕卡成幻灯片——这时候你就得问自己：这算法到底撑不撑得住？
算法效率评估，说白了就是提前预判你的代码在面对“真实世界数据量”时会不会崩。它不只看速度，还要看内存占用、扩展性，甚至未来维护成本。
时间复杂度：别被“小数据”骗了
我们常用“时间复杂度”来衡量算法随输入增长的表现。比如有个函数遍历一个数组找最大值：
int findMax(int arr[], int n) {
int max = arr[0];
for (int i = 1; i < n; i++) {
if (arr[i] > max) {
max = arr[i];
}
}
return max;
}这个循环跑了 n-1 次，所以时间复杂度是 O(n)，读作“线性阶”。意思是数据翻十倍，运行时间也大致翻十倍。听起来合理，对吧？
但如果你用两个嵌套循环比较每一对元素，比如判断是否有重复：
for (int i = 0; i < n; i++) {
for (int j = i + 1; j < n; j++) {
if (arr[i] == arr[j]) {
return true;
}
}
}这时候执行次数接近 n²/2，时间复杂度就是 O(n²)，叫“平方阶”。当 n=1000 时，操作数大约是50万；n=1万时，直接跳到5000万——指数级增长，机器很快就顶不住。
空间复杂度：内存不是大风刮来的
有些算法为了提速，会“拿空间换时间”。比如缓存中间结果，避免重复计算。这没问题，但如果每次调用都开辟一大块新内存，用户设备可能直接爆掉。
假设你写了个递归函数处理树结构，深度一深，调用栈层层叠加，内存使用就像电梯直冲顶楼。而改成迭代方式，可能只需要几个变量，空间复杂度从 O(n) 降到 O(1)。
实际场景中的取舍
公司后台要查用户订单，数据有上百万条。如果每次都从头扫一遍，用户点一下“查询”就得喝杯茶等半分钟。但加上索引（本质是用了哈希表或二叉搜索树），查询时间从 O(n) 降到 O(log n) 甚至 O(1)，体验立马不一样。
但这不代表所有地方都要追求极致效率。写个脚本处理几百行配置文件，即使用最笨的办法，多花几毫秒也没人在意。关键是分清场合：高频调用、大数据量、资源受限的场景，才需要认真评估。
怎么开始练？
下次写完一段逻辑，不妨自问两个问题：如果数据量翻100倍，这代码还能扛住吗？如果同时来10个人用，服务器会不会趴下？
再动手算一算循环层数、递归深度、存储结构。慢慢你会发现，那些看似抽象的大O符号，其实是在帮你建立对代码行为的“直觉”。就像做饭久了，不用看钟也知道面什么时候该捞起来。