应主动监控p95耗时、gc频次等微指标，通过wsgi/asgi中间件打点、tracemalloc/psutil追踪内存、line_profiler灰度分析、perf（需--with-perf编译）对齐python符号、cprofile时间窗口对比、prometheus_client.histogram按endpoint打标等手段精准定位性能回退。
怎么发现 Python 服务突然变慢了
靠用户投诉或看日志里超时记录？太被动。真实线上环境里，性能回退往往藏在平均耗时微升、P95 毛刺增多、GC 频次突增这些信号里，但默认不采集就看不到。
- 必须开启
tracemalloc或psutil做内存分配追踪，否则无法定位是对象泄漏还是缓存膨胀 - HTTP 服务建议在 WSGI/ASGI 中间件层打点，用
time.perf_counter()记录每个请求的精确耗时，别依赖日志里的%(asctime)s - 关键函数加
@profile（需line_profiler）只在灰度实例启用，全量开销太大
常见错误现象：requests.get() 耗时从 50ms 涨到 300ms，但 curl -w 测下游 API 正常——说明问题在本进程内，比如 DNS 缓存失效后同步解析阻塞主线程。
Python 3.12+ 的 perf 支持能直接用吗
不能直接用。Linux perf 默认采样的是 C 函数栈，Python 的帧对象（PyFrameObject）需要额外符号支持，否则看到的全是 _PyEval_EvalFrameDefault，看不出业务逻辑。
- 编译 Python 时必须加
--with-perf，系统 Python 包通常没开 - 运行时要设
export PYTHONMALLOC=malloc，否则perf record -e syscalls:sys<em>enter</em>* python app.py会漏掉内存分配路径 - 用
perf script -F comm,pid,tid,cpu,time,insn,ip,sym --no-children导出后，再用py-spy record对齐 Python 符号更可靠
性能影响：开 perf 采样频率 >100Hz 会导致 CPU 占用明显上升，生产环境建议 ≤50Hz，且只在问题时段临时启用。
立即学习“Python免费学习笔记（深入）”；
cProfile 抓一次就准吗
不准。单次 cProfile.run('main()') 只反映冷启动状态，而真实回退常出现在长连接维持 2 小时后、或第 1000 次调用某个 lru_cache 函数时。
- 必须做「时间窗口对比」：用
subprocess.run(['python', '-m', 'cProfile', '-o', 'prof_1.prof', 'app.py'])分别采集基线版和新版本的 profile 文件 - 用
pstats加载后，重点比对tottime（函数自身耗时）而非cumtime（含子调用），避免被 I/O 等外部因素干扰 - 注意
gc.collect()调用频次变化——如果某次发布后gc时间占比从 1% 升到 12%，大概率是循环引用没清理
容易踩的坑：用 snakeviz 可视化时，默认按 cumtime 排序，会把 requests.request 这类底层调用顶到前面，掩盖真正该优化的业务函数。
Prometheus + python-process-exporter 够用吗
不够。它只能暴露进程级指标（如 RSS、线程数、CPU%，精度到秒），但 Python 性能回退常发生在毫秒级抖动、特定请求路径、或某类输入触发的分支逻辑中。
- 必须补一层应用埋点：用
prometheus_client.Histogram按endpoint和status_code打标签，否则所有 POST 请求混在一起，看不出是 /api/v2/order 创建慢还是 /api/v2/refund 慢 - 避免在
<strong>init</strong>.py里初始化全局Counter，模块加载顺序错乱会导致指标注册失败，报错ValueError: Duplicated timeseries - 如果用 Gunicorn，要确保
--preload关闭，否则所有 worker 共享同一组 metrics 实例，计数错乱
兼容性注意：Python 3.11 引入了 ExceptionGroup，旧版 prometheus_client（
监控不是堆工具，是建立“变更—指标—代码”的快速映射链。最常被忽略的是：没把 Git commit hash 写进 metrics label，结果回滚后发现指标还在涨，才意识到是上个版本的残留缓存没清。
