微优化在python中多数无效，真正瓶颈是i/o、gil限制、低效数据结构；仅在百万级纯计算热路径中可能 measurable，但应优先优化数据库查询、http连接复用、日志级别等高影响项。
微优化在 Python 里多数时候不解决性能瓶颈
Python 的执行模型决定了 for 循环里少一次属性查找、多一个局部变量缓存，几乎不会让 Web 请求快 1ms。真正拖慢 Python 的，通常是 I/O 等待、全局解释器锁（GIL）下的 CPU 密集任务、或低效的数据结构选择。
- 典型误判：把
math.sqrt(x)换成x ** 0.5当“优化”，实际在 CPython 3.9+ 中两者耗时差异在纳秒级，且受输入大小影响远大于写法 - 真实瓶颈常出现在：
json.loads()解析大响应体、pandas.DataFrame遍历代替向量化操作、反复拼接字符串用+而非''.join() - 微优化只有在被调用数百万次的纯计算热路径中才可能 measurable——比如加密库内部循环、数值模拟内核，但这类代码通常本就该用 Cython 或 Rust 重写
哪些微优化确实值得做，且成本极低
不是所有“小改动”都白费劲。有些调整既不用改架构，又几乎零风险，还能稳稳避开解释器已知的低效路径。
- 用
local_var = obj.attr缓存频繁访问的属性，尤其在长循环中——CPython 对局部变量的查找比实例属性快 2–3 倍 - 把
re.compile(r'pattern')提到函数外或模块顶层，避免重复编译；正则对象本身是线程安全的，复用无副作用 - 用
if key in dict而非if dict.get(key) is not None判断键存在——前者是哈希表 O(1) 查找，后者多一次键哈希 + 值提取 +None比较 - 避免在循环内创建短生命周期对象，比如把
[x * 2 for x in data]改成生成器表达式(x * 2 for x in data)，当后续只消费一次时内存更友好
用 dis 和 timeit 验证，别靠直觉
Python 的优化行为高度依赖版本和实现细节。3.11 引入了自适应字节码，3.12 又调整了某些内置函数的内联策略。你“觉得快”的写法，可能在另一个环境里更慢。
- 查字节码：运行
import dis; dis.dis(lambda: a.b.c)，看是否真少了LOAD_ATTR指令 - 测真实耗时：用
timeit -s "data = list(range(1000))" "sum(x for x in data)"，而不是在 REPL 里跑一次%%timeit就下结论 - 注意陷阱：
timeit默认执行一百万次，但真实业务中某段逻辑一天只跑几十次——此时优化省下的总时间还不如一次磁盘寻道
真正该优先投入精力的地方
与其纠结 list.append() 还是 +=，不如花十分钟确认这三件事：
立即学习“Python免费学习笔记（深入）”；
- 数据库查询有没有 N+1 问题？
SELECT *拿回了根本不用的字段？ - HTTP 客户端是否复用了
requests.Session？连接池配置是否合理？ - 日志级别是不是在生产环境还开着
DEBUG？每条日志都在格式化一堆没用的上下文？
这些地方随便一个疏忽，带来的性能损失都是微优化的几百倍。而且它们都有明确可观测指标：慢查询日志、TCP 连接数、日志输出量——比猜 dict.keys() 和 dict.keys().__iter__() 哪个快实在得多。
