Python代码优化需先用cProfile定位真实瓶颈，再依场景选择算法改进、数据结构替换、内存优化或C加速；核心是测量驱动，而非直觉猜测。
Python代码优化不是简单地把for换成列表推导式，而是从运行时行为出发，看清瓶颈在哪、为什么慢、换什么更合适。关键在“先测量，再优化”，避免直觉误判。
用cProfile定位真实性能瓶颈
cProfile是Python内置最可靠的性能分析工具，能精确到函数级耗时和调用次数。不要靠猜测——90%的性能问题集中在10%的代码里。
- 基础用法：python -m cProfile -s cumulative your_script.py，按累计时间排序，一眼看出谁拖慢了整体
- 聚焦关键路径：用pstats加载结果后，执行stats.sort_stats('cumtime').print_stats(10)只看前10个耗时函数
- 注意区分tottime（函数自身耗时）和cumtime（含子调用总耗时），递归或深度调用链中后者更有参考价值
- 避免在开发机上测I/O密集型脚本——磁盘、网络波动会掩盖CPU热点；可加time.sleep()模拟稳定负载，或改用line_profiler逐行分析关键函数
算法复杂度比语法糖更重要
一个O(n²)的列表查找，哪怕写得再“Pythonic”，也干不过O(log n)的二分搜索+预排序。优化前先问：当前操作的理论下限是多少？
- 查重/交集/去重优先用set：构建O(n)，查询O(1)，比list in的O(n)快一个数量级
- 频繁插入/删除首尾元素，用collections.deque替代list——前者首尾操作O(1)，后者list.pop(0)是O(n)
- 大数据量排序别手动写冒泡或选择：内置sorted()和list.sort()是Timsort，对部分有序数据有极致优化
- 递归深度大且可转为迭代时，务必改写：Python递归开销高、有默认深度限制（sys.getrecursionlimit()），栈溢出风险真实存在
内存与对象创建：小改动带来大收益
很多“慢”其实是“频繁分配+释放”导致的GC压力，尤其在循环中创建临时对象（如字典、字符串拼接、正则Match对象）。
立即学习“Python免费学习笔记（深入）”；
- 字符串拼接不用+=：循环中s += item每次生成新字符串，O(n²)；改用list.append() + ''.join()
- 避免在循环内重复编译正则：re.compile(r'pattern')提至循环外，复用编译后的Pattern对象
- 用生成器替代一次性列表：处理大文件或流式数据时，(process(line) for line in file)比[process(line) for line in file]省内存且启动更快
- 小而固定的对象考虑__slots__：类定义中加入__slots__ = ('x', 'y')可禁用__dict__，减少单实例内存占用20%-50%
适时引入C加速：Cython、NumPy与Numba
纯Python无法突破解释器瓶颈时，就该让C来干活。但别一上来就写C扩展——优先选封装好的高性能库。
- 数值计算一律转向NumPy：向量化操作自动利用底层C/Fortran，比Python循环快10–100倍；注意避免np.array在循环里反复构造
- 计算密集型函数用Numba：加个@jit(nopython=True)装饰器，无需改逻辑，JIT编译后接近C速度（支持常见numpy操作和循环）
- 已有C/C++代码或需极致控制时，用Cython：.pyx文件写法接近Python，通过cdef声明类型、prange并行化，编译成.so直接import
- 注意GIL：纯计算函数用Numba或Cython可释放GIL，支持多线程并行；但涉及Python对象操作（如调用内置函数、操作list/dict）仍受GIL限制
