先排查隐性环节而非SQL——真实瓶颈常常藏在DNS解析、连接池重建、SSL握手或中间件阻塞里。需要用SkyWalking这样的APM工具来定位全链路耗时分布，而flask_profiler只能统计Python层内部时间，无法覆盖网络I/O与连接建立这些关键环节。
Flask接口慢，先别急着优化SQL
遇到接口慢的问题，先别急着对着SQL撸EXPLAIN，也别随手加个@lru_cache就以为万事大吉。绝大多数时候，问题根本不在业务逻辑或数据库查询里，而卡在请求链路的某个隐性环节：DNS解析超时、连接池重建、SSL握手阻塞、中间件异常挂起，甚至WSGI服务器配置错误。直接看EXPLAIN或加@lru_cache往往白忙一场。
真实排查顺序应该是：先确认耗时分布（是网络层？Python层？下游依赖？），再逐段收窄。APM不是“锦上添花”，而是定位这类问题的最小可行手段。
用SkyWalking快速接入Flask入口追踪
SkyWalking Python Agent是目前对Flask支持最稳的APM工具，但有个坑：必须手动注册装饰器，否则它压根不采集HTTP入口的span。具体操作并不复杂：
- 安装：
pip install skywalking-python（注意别用已废弃的skywalking-agent） - 启动前设好环境变量：
SW_AGENT_NAME=flask-api、SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 - 每个路由函数必须加
@sw.entry()，例如：@app.route('/api/users')@sw.entry()def list_users(): return jsonify(User.query.all()) - 异步视图函数（
async def）需额外用@sw.async_trace()包裹，否则子调用全丢
为什么Flask-Profiler不够用
flask_profiler能告诉你/api/users平均耗时320ms，但无法回答这个320ms里，140ms花在Redis GET、80ms卡在MySQL connect、60ms等DNS解析、剩下40ms才是Python执行——它只统计WSGI应用内部时间，不包含网络I/O、连接建立、中间件前置处理等关键环节。
典型失效场景包括：
- 容器内访问
127.0.0.1:5000慢，实际是DNS查localhost超时，flask_profiler显示耗时正常，SkyWalking则会暴露connect阶段长达14s - 使用
requests.get('https://xxx')调第三方API，flask_profiler只计时到requests返回，SkyWalking能拆出TCP握手、TLS协商、服务端处理三段耗时 - 多个微服务串联调用，
flask_profiler只管本服务，SkyWalking自动透传trace_id，整条链路一目了然
排查时最容易忽略的三个点
接入APM后仍找不到瓶颈，大概率栽在这三处：
SW_AGENT_COLLECTOR_BACKEND_SERVICES地址写错或端口不通，导致trace数据根本没发出去，界面看起来“没数据”或只有空白span- Flask用了
before_request中间件做鉴权/日志，但其中某段代码（比如同步调用Redis）阻塞了主线程，APM能捕获，但你需要主动展开span树看子节点耗时 - 本地开发启用了
debug=True，Werkzeug重载机制会干扰trace上下文传递，导致span断连；上线前务必关掉debug并验证SW_AGENT_IS_INSTRUMENTATION_ENABLED为True
链路追踪不是装完就灵，真正难的是看懂span里的peer.hostname、http.status_code、error tag，以及识别出那些“看似成功但耗时异常”的下游调用。
