Python性能优化需先明确目标（延迟/吞吐/内存），再用cProfile定位真实瓶颈，避免误判；__slots__仅在实例极多时有效；lru_cache须确保函数纯且参数可哈希；asyncio仅适用于I/O密集型任务。
Python性能优化没有银弹，但有清晰的排查路径和可验证的改进手段。盲目改代码、换工具、加缓存，往往治标不治本。
用 cProfile 定位真实瓶颈，别靠猜
90% 的性能问题不在算法复杂度，而在 I/O 阻塞、重复序列化、低效循环或意外的深拷贝。直接跑 python -m cProfile -s cumulative your_script.py，看 cumulative 列——它反映函数及其调用链总耗时，比 tottime 更能暴露“谁拖垮了整个流程”。
常见误判：
- 看到
json.loads耗时高，就以为是 JSON 解析慢；实际可能是上游传入了超大字符串，或反复解析同一段内容 -
__init__出现在顶部？检查是否在循环里新建了带 heavy setup 的对象 - 大量
line 1或
理解 __slots__ 和 __dict__ 对内存与访问速度的实际影响
__slots__ 不是万能加速器。它只在类实例极多（数万以上）、且属性固定时才显著降低内存占用并加快属性访问。启用后，实例将失去动态添加属性的能力，__dict__ 也被禁用。
实操建议：
- 先用
sys.getsizeof(instance)和objgraph.show_most_common_types(limit=20)看内存大户是不是你的类实例 - 对比开启前后：
timeit测属性读写，psutil.Process().memory_info().rss看进程常驻内存变化 - 避免在父类用
__slots__、子类不用——这会导致子类实例仍带__dict__，且额外多一个空字典开销
用 functools.lru_cache 前必须确认函数纯度与参数可哈希性
lru_cache 缓存的是函数调用结果，不是
“让代码变快”的开关。一旦函数依赖外部状态（如全局变量、文件内容、数据库连接），缓存会返回陈旧甚至错误结果。
典型翻车场景：
- 参数含
list或dict：直接报TypeError: unhashable type，必须转成tuple或frozenset，或改用cache = {}手动控制 - 函数内部调用了
time.time()或random.random()：缓存使结果“冻结”，行为失真 - 缓存大小设为
maxsize=None但键空间无限（如带时间戳的请求参数）：内存持续增长，最终 OOM
异步不是性能解药，asyncio + httpx 只对 I/O 密集型有效
CPU 密集任务（如图像处理、数值计算）用 asyncio 不仅不提速，反而因事件循环调度引入额外开销。真正受益的是并发 HTTP 请求、数据库查询、文件读写等阻塞操作。
关键判断点：
- 单次请求耗时 > 100ms 且并发量 ≥ 10？适合上
asyncio.gather - 用
httpx.AsyncClient替代requests，但必须确保所有下游服务支持 HTTP/1.1 pipelining 或 HTTP/2 - 混合 CPU + I/O 任务？用
loop.run_in_executor把 CPU 工作扔进concurrent.futures.ProcessPoolExecutor，别全塞进协程
性能优化最易被忽略的一点：你优化的到底是延迟（latency）、吞吐（throughput），还是内存驻留（RSS）？三者目标冲突。降低延迟可能增加内存开销，提升吞吐可能拉高平均延迟。先定义可观测指标，再选工具和策略。
