写程序时，很多人一看到“快”就激动，觉得算法厉害。可实际用起来却发现，代码跑得并不如预期。问题往往出在评估方式上，只看理论或单一指标，容易踩坑。
别光盯着时间复杂度
教科书里常说 O(n²) 比 O(n log n) 慢，这没错，但现实没那么简单。比如你处理的数据量很小，n=50，那 O(n²) 的算法可能比 O(n log n) 还快，因为前者常数小，实现简单。就像去楼下买瓶水，走路两分钟，打车反而要等，还绕路。
考虑真实数据特征
算法在随机数据上表现好，不代表在你的业务数据里也行。比如快速排序在大部分情况下很快，但如果输入已经是有序的，性能会退化到 O(n²)。如果你的用户经常上传按时间排序的日志，那就要小心了。
空间换时间？内存够不够得算清楚
哈希表查找快，O(1)，但它占内存。在手机 App 里用个大哈希表缓存所有数据，可能直接被系统杀掉。评估时得看运行环境，嵌入式设备和服务器能用的资源差太多了。
实测别偷懒，用真实场景压测
写个循环跑一万次加法，看不出啥问题。应该模拟用户行为，比如一个电商搜索功能，不仅要测响应时间，还要看并发时的表现。可以用 Python 简单测一下：
import time
start = time.time()
# 模拟你的算法处理过程
result = [i ** 2 for i in range(100000)]
end = time.time()
print(f"耗时: {end - start:.4f} 秒")注意语言和平台差异
同一个算法，用 C 写和用 JavaScript 写，性能天差地别。JavaScript 在 V8 引擎里有 JIT 优化，但频繁创建对象也会拖慢速度。别拿 Python 脚本的测试结果去推断 Java 服务的性能。
小改动可能带来大影响
有时候加一行缓存，就能让接口从 500ms 降到 50ms。反过来，一个没必要的深拷贝，也可能让列表操作慢十倍。别忽视细节，尤其是循环内部的操作。
评估算法效率，不是做数学题，而是结合场景做判断。理论是基础，实测是关键，环境是变量。多问自己：我的用户会遇到什么数据？跑在什么设备上？有没有边界情况？想清楚这些，才不容易被纸面数字带偏。