绝大多数时候不该为性能牺牲可读性，仅当profiler确认真实瓶颈且优化带来>10%整体提速时才考虑；须用timeit、cprofile验证，优先信任标准库高效接口。
什么时候该为性能牺牲可读性
绝大多数时候不该。Python 的设计哲学是“可读性第一”，readability counts 不是口号，是解释器和标准库的实际取舍依据。只有当 profiler 明确指出某段代码是真实瓶颈（比如在热循环里调用 sum() 一万次），且优化后能带来 >10% 整体耗时下降，才值得动。
常见误判场景：
- 用 map() 替代列表推导式，只因“听说更快”——实际在 CPython 中，简单表达式下列表推导式通常更快、更直观
- 过早把 for 循环改成 itertools.chain() + filter() ——嵌套函数调用开销可能抵消掉算法优势
- 为省一个临时变量，把 data.strip().lower().replace(' ', '_') 写成一行长链——调试时无法 inspect 中间值，出错连具体哪步崩了都难定位
哪些“可读性优化”其实悄悄拖慢了性能
看似清晰的写法，有时自带隐式开销。关键看是否触发重复计算、对象创建或低效协议调用。
典型例子：
- 在循环内反复调用 len(my_list) ——每次都是 O(1)，但 Python 解释器要查属性、进函数栈，不如提前存成 n = len(my_list)
- 用 str.format() 拼接大量字符串（尤其在循环中）——比 f-string 多一层解析开销，且生成临时对象；'%s' % x 更快但可读性差，f-string 是平衡点
- 把 if key in dict: 写成 if key in list(dict.keys()): ——后者强制转成 list，O(n) 查找，而前者是哈希查找 O(1)
用对工具才能看清真实代价
凭感觉判断“这里慢”或“那里可读”基本靠不住。Python 的性能热点往往反直觉，比如字符串拼接、小函数调用、属性访问的开销分布。
必须做的三件事：
- 先用 timeit 对比候选写法：比如 timeit.timeit('a + b + c', setup='a,b,c="x","y","z"') 和 timeit.timeit('"".join([a,b,c])', ...)
- 热点函数用 cProfile.run('main()') 或 line_profiler 定位到行级耗时
- 测试数据规模要贴近真实：用 10 条数据看不出区别，得上 10k 行日志或 100MB 文件再测
注意：__slots__ 能减内存、加速属性访问，但会禁用动态属性和 __dict__，调试/序列化时容易卡住——除非你真在做高频实例化（如百万级 ORM 对象），否则别加
立即学习“Python免费学习笔记（深入）”；
标准库里那些“又快又清楚”的默认选择
CPython 标准库的很多接口，是可读性与性能反复权衡后的结果。优先用它们，而不是自己造轮子或强行“优化”。
值得无脑信任的组合：
- 字符串分割统一用 str.split()（不带参数），它比 re.split(r'\s+', s) 快 3–5 倍，且语义更明确
- 列表去重保留顺序：用 list(dict.fromkeys(items)) ——比手写 seen = set(); [x for x in items if not (x in seen or seen.add(x))] 清晰、安全、不依赖副作用
- 计数统计直接上 collections.Counter，比手动 dict 累加少写逻辑、少犯键不存在错误，底层还是 C 实现
- 文件读取优先 pathlib.Path.read_text() 而非 open().read() ——少两行代码、自动处理编码、异常更精准，性能差异可忽略
真正复杂的地方从来不是单行代码快不快，而是数据结构选型、IO 批处理粒度、缓存策略这些层面上的取舍——这些地方没 profile 数据支撑，谈性能就是纸上谈兵
