py-spy可实时诊断运行中Python进程，无需改代码、不重启、不影响流量；前提是权限到位（如sudo或SYS_PTRACE）、进程存活、采样时长足够，且多进程需显式启用--subprocesses。
能直接对运行中的 Python 进程做实时诊断，不用改代码、不重启服务、不影响线上流量——前提是权限和进程状态到位。
py-spy record 生成火焰图时 profile.svg 打不开或为空
这不是工具坏了，而是采样没真正发生。常见原因有三个：
- 目标进程在 py-spy 启动前就退出了，比如脚本执行完立刻结束；用
ps aux | grep your_script.py确认 PID 是否真实存在 - 默认只采样 30 秒，但程序本身跑得比这还短；加
-d 60显式延长采样时长：py-spy record -d 60 -o profile.svg --pid 12345 - 生成的文件头部不含
<svg，说明写入中断；大概率是权限失败（见下一条）或磁盘满
py-spy top 报 Permission denied 或卡在 “Waiting for process…”
Linux 默认禁止非特权进程读取其他进程内存，py-spy 依赖 process_vm_readv 系统调用，必须有 SYS_PTRACE 权限。
- 本地调试：用
sudo py-spy top --pid 12345（仅临时调试，别上生产） - Docker：启动容器时加
--cap-add=SYS_PTRACE -v /proc:/proc:ro - Kubernetes：Deployment 的
securityContext.capabilities.add必须包含["SYS_PTRACE"]，且/proc挂载为只读 - 额外检查：
cat /proc/sys/kernel/yama/ptrace_scope值为 1 时，即使有 cap 也可能失败；调试可临时设为 0，生产环境保持 1
分析多进程 Web 服务（如 Gunicorn/UWSGI）时只看到主进程
默认情况下 py-spy 不自动跟踪子进程，而 Web 服务器通常 fork 出多个 worker，瓶颈往往藏在 worker 里。
立即学习“Python免费学习笔记（深入）”；
- 加
--subprocesses参数：例如py-spy record --subprocesses -o all.svg --pid 12345 - 如果已知某个 worker PID，直接指定：
py-spy top --pid 12346 - 注意：
--native可同时分析 C 扩展（如 numpy、cryptography），但会略微增加开销，生产慎用
最易被忽略的一点：py-spy 的“无侵入”只针对目标 Python 进程本身，但它对宿主机的权限要求非常具体——不是装上就能跑，而是每一步都卡在操作系统级限制上。尤其在容器或 K8s 环境中，漏掉 /proc 只读挂载或 SYS_PTRACE 能力声明，就会全程静默失败。
