搞懂时间复杂度，写出更快的 Python 代码

原创于 2026-04-28 16:13:33 发布 · 126 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#Python #时间复杂度，算法优化，大 O 表示法

为什么你的代码跑不动？从时间复杂度说起

很多刚接触 Python 的朋友在写脚本时，往往只关注“功能是否实现”，却很少在意“跑得有多快”。在小数据量下，这种差异几乎不可感知；但一旦数据规模扩大到几万、几十万行，原本几秒能跑完的程序可能突然变成需要跑几个小时，甚至直接让内存爆掉。这背后的核心原因，通常不是硬件不够强，而是算法的时间复杂度没选对。

时间复杂度并不是一个玄学的概念，它本质上是一种评估算法效率的数学工具。我们不需要成为数学家也能掌握它，只要理解大 O 表示法（Big O Notation）的核心逻辑，就能在编写排序、查找或数据处理逻辑时，做出更明智的选择。

读懂大 O 表示法：关注增长趋势而非绝对时间

当我们讨论算法快慢时，很多人第一反应是“这段代码跑了 0.5 秒，那段跑了 1.2 秒”。这种基于绝对时间的对比其实非常不可靠，因为它严重依赖测试机器的 CPU 性能、当前负载以及解释器的版本。今天在你的电脑上快，明天换台服务器可能就慢了。

大 O 表示法摒弃了具体的运行时间，转而关注输入数据规模（通常用 n 表示）增长时，算法执行步骤的增长趋势。简单来说，它回答的问题是：“如果数据量扩大 10 倍、100 倍，我的代码运行时间会扩大多少倍？”

如果数据量翻倍，运行时间也大致翻倍，这是线性增长。
如果数据量翻倍，运行时间变成了原来的四倍，这是平方级增长。
如果无论数据量多大，运行时间都基本不变，这是常数级增长。

在 Python 开发中，我们通常只关心最坏情况下的表现，因为那决定了系统的下限稳定性。通过大 O 表示法，我们可以忽略掉那些次要的系数和低阶项，直接抓住影响性能的主要矛盾。

常数阶 O(1)：理想的高效模式

常数阶 $O(1)$ 是算法效率的“天花板”。这意味着无论你的列表里有 10 个元素还是 1000 万个元素，代码执行的操作次数都是固定的，不会随数据规模增加而变慢。

在 Python 中，最典型的 $O(1)$ 操作是字典（dict）的键值访问和列表的索引访问。

# 典型的 O(1) 操作
user_data = {"id": 1001, "name": "Alice", "role": "admin"}

# 无论字典多大，获取 name 的速度几乎一样快
role = user_data["role"] 

numbers = [i for i in range(1000000)]
# 直接通过索引取值，也是 O(1)
first_item = numbers[0]
last_item = numbers[-1]

当你需要频繁查找某个元素是否存在，或者需要根据键快速获取值时，优先考虑使用字典或集合（set），而不是遍历列表。例如，判断一个用户 ID 是否在黑名单中，用 if uid in black_list_set: 的效率远高于 if uid in black_list_list:，前者是 $O(1)$，后者则是 $O(n)$。

养成习惯：在设计数据结构时，思考一下“我是否需要频繁查找？”如果是，哈希表（Python 中的 dict/set）通常是首选。

线性阶 O(n)：最常见的处理逻辑

线性阶 $O(n)$ 意味着算法的执行时间与输入数据的大小成正比。数据量扩大 10 倍，耗时也大约扩大 10 倍。这是大多数基础数据处理任务的常态，虽然不如 $O(1)$ 完美，但在很多场景下已经是可接受的最优解。

典型的 $O(n)$ 场景包括遍历列表、简单的查找以及列表推导式。

# 典型的 O(n) 操作：遍历求和
def calculate_total(prices):
    total = 0
    for price in prices:
        total += price
    return total

# 典型的 O(n) 操作：线性查找
def find_user(users, target_id):
    for user in users:
        if user["id"] == target_id:
            return user
    return None

上面的 find_user 函数在最坏情况下（目标在最后或不存在）需要检查每一个元素。如果 users 列表很小，这完全没问题；但如果这是一个包含百万级用户的日志列表，且你需要对每个请求都执行一次查找，系统响应速度就会显著下降。

优化思路很简单：如果查找操作非常频繁，不妨在程序初始化时，将列表转换为以 ID 为键的字典。虽然构建字典本身需要 $O(n)$ 的时间，但后续的每次查找都将降为 $O(1)$，总体收益巨大。

平方阶 O(n²)：性能杀手与嵌套陷阱

平方阶 $O(n^2)$ 是新手最容易踩的坑，也是导致程序“卡死”的常见元凶。当代码中出现双重嵌套循环，且内层循环的次数依赖于外层循环的变量时，往往就会出现这种情况。数据量只要稍微增大，运行时间就会呈指数级爆炸。

想象一下，如果 $n=1000$，$n^2$ 就是 100 万次操作；如果 $n=10000$，那就是 1 亿次操作。这种量级的差异在本地测试小数据时很难被发现，一旦上线就是事故。

# 典型的 O(n²) 操作：冒泡排序思想或两两对比
def find_duplicates(items):
    duplicates = []
    # 外层循环
    for i in range(len(items)):
        # 内层循环：每次都从头比对（低效写法）
        for j in range(len(items)):
            if i != j and items[i] == items[j]:
                if items[i] not in duplicates:
                    duplicates.append(items[i])
    return duplicates

上面的代码为了找出重复项，让每个元素都和其他所有元素比了一遍。其实我们完全可以用更高效的方式重写它，利用集合的特性将复杂度降回 $O(n)$：

# 优化后的 O(n) 写法
def find_duplicates_optimized(items):
    seen = set()
    duplicates = set()
    for item in items:
        if item in seen:
            duplicates.add(item)
        else:
            seen.add(item)
    return list(duplicates)

除了手动写的嵌套循环，一些看似简洁的代码也可能隐藏 $O(n^2)$ 的风险。比如在列表中频繁使用 pop(0) 删除第一个元素，因为每次删除后后面的元素都要向前移动一位，如果在循环中这样做，整体复杂度也会退化为平方级。在处理大规模数据排序时，尽量避免自己手写冒泡或选择排序，直接使用 Python 内置的 sorted() 或 list.sort()，它们基于 Timsort 算法，平均复杂度是 $O(n \log n)$，远优于 $O(n^2)$。