在开发赛事管理系统时，我们常常需要从一份原始对战记录中统计每个团队的获胜次数。如果直接采用最直观的嵌套循环做法，随着数据量增长，程序响应会变得非常慢。理解其性能瓶颈并改用合适的数据结构，是提升统计效率的关键。
原始嵌套循环的实现方式
最容易被新手想到的方案是：外层循环遍历每一条比赛记录，内层循环再去匹配对应的队伍并判断胜负。这种做法在逻辑上直白，但计算复杂度会随着记录数增加呈平方级恶化。
下面是一段典型的嵌套循环代码，它从matches列表中提取胜者，并在teams里查找后累加。注意内层使用了列表的count或者遍历操作，导致每条记录都要扫一遍队伍信息。
matches = [
('A', 'B', 'A'),
('B', 'C', 'B'),
('A', 'C', 'A'),
('C', 'B', 'C')
]
teams = ['A', 'B', 'C']
win_count = {t: 0 for t in teams}
for match in matches:
winner = match[2]
for team in teams:
if team == winner:
win_count[team] += 1
print(win_count)
上述代码在小数据量时没有问题，但teams和matches都可能膨胀到几万行。此时内层for循环反复执行，不仅做了大量无用比较，还让CPU缓存命中率下降。我们可以用时间复杂度公式说明：若matches有m条、teams有n个，则总操作接近m乘n。
另一个隐藏问题是，如果teams来源于数据库查询且未建索引，每次循环都相当于一次线性查找。即便用列表的index方法，本质也还是遍历。因此这种写法在真实业务里往往成为接口超时的元凶。
使用哈希表优化统计逻辑
优化的核心思想是把队伍胜场直接映射到字典的键上，利用哈希表O(1)的查找特性消除内层循环。Python的collections.defaultdict正好适合这种累加场景。
改写后的代码完全不需要嵌套，只遍历一次比赛记录，对胜者名字对应的计数器加一即可。即使teams列表很长，也不再影响主循环开销。
from collections import defaultdict
matches = [
('A', 'B', 'A'),
('B', 'C', 'B'),
('A', 'C', 'A'),
('C', 'B', 'C')
]
win_count = defaultdict(int)
for match in matches:
winner = match[2]
win_count[winner] += 1
# 若需确保未获胜队伍也出现在结果中
teams = ['A', 'B', 'C']
final = {t: win_count.get(t, 0) for t in teams}
print(final)
这段代码将复杂度降为O(m)，因为字典写入和读取都是平均常数时间。当matches达到十万级时，原先嵌套写法可能耗时几秒甚至更长，而新写法则在毫秒级完成。同时代码行数减少，可读性和维护性都更好。
如果业务要求只统计特定队伍，也可以先把这些队伍放进set，在循环里用if winner in team_set来过滤，依然保持单层结构。set的in操作同样是哈希实现，不会退化成遍历。
两种方案的性能对比与适用建议
为了直观看到差异，我们构造一个万级数据的测试。下面的脚本用随机生成的队伍和胜者模拟真实日志，并分别计时。
import random
from collections import defaultdict
import time
teams = [f'T{i}' for i in range(500)]
matches = [(random.choice(teams), random.choice(teams), random.choice(teams)) for _ in range(20000)]
# 嵌套循环版本
start = time.time()
wc1 = {t: 0 for t in teams}
for m in matches:
for t in teams:
if t == m[2]:
wc1[t] += 1
print('嵌套循环耗时:', time.time() - start)
# 哈希版本
start = time.time()
wc2 = defaultdict(int)
for m in matches:
wc2[m[2]] += 1
final2 = {t: wc2.get(t, 0) for t in teams}
print('哈希版本耗时:', time.time() - start)
在普通笔记本上运行，嵌套循环常常超过两秒，而哈希版本一般低于零点零五秒。差距主要来自内层五百次无效比对被彻底移除。若队伍数扩大到五千，嵌套循环可能直接卡死，哈希版仍平稳。
实际工程中，如果数据已经落在数据库，更推荐用SQL的GROUP BY直接算出胜场，避免在应用层做循环。但面对本地日志、内存中的临时列表时，把嵌套循环重构成字典累计，是最简单且收益明显的优化手段。
常见误区与排查思路
有的开发者尝试在嵌套循环里加break来提升速度，例如找到队伍后就跳出内层。这确实能减少一些比较，但复杂度依旧是O(m乘n)，只是常数变小，数据翻十倍耗时还是近百倍增长，不能从根本上解决问题。
还有人把teams转成pandas的Series再做映射，虽然也能跑，但引入了额外依赖和内存转换成本。对于纯统计胜场的轻量任务，标准库defaultdict足够胜任，没必要过度引入框架。
排查此类性能问题，可以用cProfile模块打印函数耗时，重点看哪一层循环占用了最多时间。一旦发现两层for紧紧嵌套且内层在做成员判断，就可以优先考虑用哈希结构平铺。