微优化通常不值得投入时间，除非代码已确认为性能瓶颈；真正有效的微优化仅限I/O绑定、高频循环（10⁵+次）和对象创建热点三类场景。

微优化在 Python 里通常不值得投入时间

除非你已确认某段代码是性能瓶颈，否则改 sum() 为 math.fsum()、把 for 换成 map()、或用 += 替代 + 拼接字符串，几乎不会带来可测量的收益。CPython 解释器本身开销远大于这些操作的差异，而开发者的时间成本远高于几纳秒的节省。

哪些微优化真有影响？只看三类场景

真正值得动手的微优化集中在：I/O 绑定、高频循环（10⁵+ 次）、以及对象创建热点。其他都是幻觉。

• 字符串拼接：在长循环中用 list.append() + ''.join()，而非 += —— 因为后者每次都会新建字符串对象
• 属性访问：在 tight loop 里缓存 obj.method 为局部变量，避免重复查找（func = obj.method; for _ in range(100000): func()）
• 内置函数调用：用 len(seq) 而非 seq.__len__()，用 isinstance(x, int) 而非 type(x) is int —— 前者走 C 快路径，后者多一层解析

用 cProfile 和 line_profiler 验证，别猜

90% 的“慢代码”根本不在你怀疑的位置。没跑过 cProfile.run('main()') 就改逻辑，等于蒙眼调参。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• cProfile 找出耗时 top 3 的函数
• @profile 装饰 + kernprof -l -v script.py 查具体哪一行吃 CPU
• 注意：测试数据量要接近真实场景，空列表 or 单元素 case 下的“优化”毫无意义

更值得做的其实是“宏观优化”

把一个 O(n²) 的嵌套遍历改成哈希表查找，比把 range(1000) 换成 xrange(1000)（Python 2）或直接删掉（Python 3）有用一百倍。

立即学习“Python免费学习笔记（深入）”；

• 优先考虑算法替换（如用 collections.Counter 替代手写计数 dict）
• 批量替代单次（如用 cursor.executemany() 而非循环 execute()）
• 延迟计算（用生成器表达式 (x*2 for x in data) 替代列表推导，尤其当结果不全用时）

真正的性能拐点往往藏在抽象层级之间，而不是某个运算符的选择上。