Py-Spy 采集时进程无响应并非挂起，而是默认用 ptrace 暂停进程采样所致；若进程本就在 I/O 等待，暂停后更显“卡死”，属正常设计。
Py-Spy 采集时进程没反应，是不是挂了？
不是挂了，是 Py-Spy 默认用 ptrace 暂停目标 Python 进程采样，如果目标进程本就在等待 I/O（比如卡在数据库查询、HTTP 请求或锁竞争），暂停后看起来像“卡死”，其实只是采样期间被冻结了。这不是 bug，是设计使然。
实操建议：
- 用
py-spy record -p <pid> -d 30 --duration 30</pid>控制总采样时长和单次暂停间隔，避免长时间阻塞业务 - 若进程对延迟极度敏感（如实时服务），改用
--nonblocking模式（仅 Linux 支持），它不暂停进程，但采样精度略低、可能漏掉短生命周期函数 - 确认目标进程确实还在运行：
kill -0 <pid></pid>不报错即存活；ps -o pid,ppid,stime,etime,comm -p <pid></pid>看运行时长和父进程是否异常
火焰图里 select 和 epoll_wait 占比高，说明什么？
这不代表 Python 代码慢，而是主线程大部分时间在事件循环空转或等待系统调用返回——典型表现是 CPU 使用率低但响应延迟高。常见于异步框架（如 FastAPI + Uvicorn、Tornado）中协程未及时调度，或阻塞调用混入异步路径。
关键判断点：
立即学习“Python免费学习笔记（深入）”；
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
-
select高：多见于旧版 Python 或未启用asyncio优化的环境（如 Python asyncio.set_event_loop_policy） -
epoll_wait高：Linux 下正常，但若占比 >70% 且业务逻辑函数几乎不出现，说明协程几乎没执行，大概率有同步阻塞操作（如time.sleep(1)、requests.get()、未用await的数据库驱动） - 检查是否误用了同步 SDK：比如在 FastAPI 路由里直接调
redis.Redis().get()而非aioredis
火焰图中函数名全是 <unknown></unknown> 或地址（如 0x7f9a2b1c3456）
这是符号表缺失导致 Py-Spy 无法解析函数名，常见于：Python 用源码编译但没开调试符号、使用了 PyOxidizer / PyInstaller 打包、或 C 扩展模块未提供 debug info。
解决路径：
- 本地开发环境重装 Python 时加
--with-pydebug或确保python3-dbg包已安装（Ubuntu/Debian） - 容器中运行时，在基础镜像里显式安装调试符号：
apt-get install -y python3-dbg（Debian 系）或dnf debuginfo-install python3（RHEL 系） - PyInstaller 打包需加
--debug和--strip=False；PyOxidizer 配置中设strip = false并启用python_config.debug = true - 临时验证：运行
py-spy top -p <pid></pid>，若能看到函数名，说明问题出在录制模式的符号加载环节，可加--dump-memory强制读内存符号
为什么同样的代码，Py-Spy 在开发机上能定位热点，线上却只看到 PyEval_EvalFrameEx 一整条竖线？
这是 Python 帧对象未展开的表现，本质是 Py-Spy 未能获取完整的调用栈上下文，主因是线上环境禁用了 Python 的帧对象访问机制——常见于启用了 faulthandler、gdb 冲突，或更大概率：Python 启动时加了 -O 或 -OO 优化参数。
必须检查的点：
- 查启动命令：
ps aux | grep python看是否有-O；Dockerfile 中是否写了ENV PYTHONOPTIMIZE=1 -
-O会剥离assert和__doc__，同时让sys._current_frames()返回空，Py-Spy 就只能拿到最顶层的 C 函数（即PyEval_EvalFrameEx） - 线上环境不要用
-O启动性能分析中的服务；若必须优化，至少保留-O1（不删 docstring），并确认sys.getsizeof(sys._current_frames()) > 0
火焰图不是万能的，它只反映“谁在 CPU 上跑了多久”。IO 延迟、GIL 争抢、内存分配抖动、甚至 DNS 解析超时，都不会直接出现在火焰图顶部——这些得靠 py-spy dump 看线程状态、strace -p <pid> -e trace=network,io</pid> 补充抓包，或者 perf record -e syscalls:sys<em>enter</em>* -p <pid></pid> 定位系统调用瓶颈。
