cprofile 是定位 python cpu 瓶颈最轻量可靠的标准库工具，应聚焦剖析目标函数段并按 cumtime 排序，避免被初始化噪声干扰；需注意其不统计 c 扩展内部耗时，且高频小操作（如 list.append、字符串拼接、重复 len 调用）和动态属性访问（__getattr__）常成隐形热点。
用 cProfile 快速定位耗时函数
Python 的 CPU 瓶颈往往藏在某个看似普通的循环或嵌套调用里，cProfile 是最轻量、最可靠的起点。它不依赖外部工具，标准库自带，且开销可控。
常见错误是直接对整个脚本跑 python -m cProfile script.py，结果被初始化、导入等噪声淹没。更有效的方式是只剖关注的函数段：
- 用
@profile装饰器（需配合kernprof）太重，不如直接插cProfile.run('your_function()', sort='cumtime') - 排序参数选
'cumtime'（累计时间），比'tottime'更容易发现“谁拖慢了整条调用链” - 注意
cProfile不统计 C 扩展内部耗时（比如numpy的底层计算），若看到大量时间卡在<built-in method numpy.></built-in>，说明瓶颈其实在数据规模或算法选择上，不是 Python 层代码问题
识别 list.append() 和字符串拼接这类隐式开销
高频小操作在 Python 里可能比你想象中贵得多——尤其当它们出现在 tight loop 中。这不是语法错，是对象模型和内存分配机制决定的。
典型场景：读文件逐行处理、构建日志消息、组装 SQL 参数列表。
立即学习“Python免费学习笔记（深入）”；
-
result = []后反复result.append(x)没问题；但result += [x]或result = result + [x]每次都新建 list，O(n²) 复杂度 - 字符串拼接用
+=在 CPython 3.12+ 有优化，但跨函数、多线程或含 Unicode 组合字符时仍不稳定；稳妥做法是收集到list再''.join(parts) - 如果循环里调用了
len(my_list)多次，别以为它是 O(1) 就放心——解释器不会帮你缓存，每次都是查对象头；提前提取n = len(my_list)更干净
区分 time.time() 和 time.perf_counter() 的适用场景
测 CPU 时间不是越“准”越好，而是要匹配你真正想回答的问题。用错计时器会导致结论完全偏移。
比如你想知道“这段代码在 CPU 上实际花了多久”，而不是“从开始到结束墙上过了几秒”。
-
time.time()返回系统时钟，受 NTP 调整、睡眠、进程调度影响，适合测“真实耗时”，不适合性能分析 -
time.perf_counter()是单调递增高精度计时器，专为性能测量设计；但它包含等待 I/O 的时间（比如input()、time.sleep()），所以必须确保测试段纯 CPU 计算 - 更严格的场景（如对比两个算法），用
timeit模块更可靠，它自动处理循环、GC 关闭、多次运行取最小值等细节
警惕 __getattr__ 和属性访问的意外开销
动态属性访问看起来优雅，但每次触发 __getattr__ 都是一次完整的函数调用 + 字典查找 + 可能的异常抛出，比普通属性访问慢 10–100 倍。
常见于 ORM 模型、配置对象、mock 对象封装等场景。
- 如果类里写了
def __getattr__(self, name): return self._data.get(name)，而业务代码高频访问obj.field_name，这就是隐形热点 - 替代方案：在
__init__中预设所有可能字段（哪怕值为None），或用__slots__锁定属性集，彻底绕过__getattr__ - 用
hasattr()判断前先确认是否真需要——它内部就是靠捕获AttributeError实现的，比直接访问还多一次异常开销
真正的瓶颈往往不在大函数里，而在你每天写十遍、觉得“肯定没问题”的那几行小操作上。比如一个被调用十万次的 getattr(obj, 'x', None)，换成 obj.__dict__.get('x') 可能快一倍，但前提是它确实存在且没被 property 覆盖——这种细节，不看 cProfile 输出根本意识不到。
