1. 报错现场一个看似“莫名其妙”的性能分析异常先看一段触发了这个报错的代码import cProfile prof cProfile.Profile() # 注意这里没有调用 prof.enable() 或 prof.enable() 在别处被调用了但没有生效 # ... 执行需要分析的代码 ... prof.disable()运行后控制台直接甩出一段红字ProfilerNotRunningError: Cannot stop profiling. No profiler is running.第一次碰到这个报错的人第一反应通常都是“我明明创建了 Profile 对象也调用了 disable为什么会说没有 profiler 在运行”这个问题的坑在于cProfile.Profile和profile.Profile这两个模块的设计和工作方式跟很多人的直觉不太一样。你“创建了对象”不等于“profiler 在运行”两者是完全独立的两回事。很多做性能分析的新手甚至一些写过几年 Python 的开发者都在这里栽过跟头。这篇博文把这个报错的来龙去脉、产生场景、正确用法以及我实际踩坑后总结的排查思路一次性讲清楚。2. 报错根源enable/disable 必须成对出现2.1 Profile 对象的两种状态理解这个报错先要理解Profile对象的内部机制。一个 profiler 对象内部有一个非常关键的状态标志——你叫它 running 标志也好active 标志也罢。这个标志决定了 profiler 当前是否处于“采集性能数据”的状态。Profile对象刚被创建出来时这个标志是 False表示没有在运行。只有当你调用了prof.enable()之后这个标志才变成 Trueprofiler 才开始真正地采样每个函数的调用次数、耗时等数据。当你调用prof.disable()时正常情况下应该会把这个标志重新置为 False停止采样然后生成一份统计报告。disable()在设计上非常“严谨”——它会在停止之前先检查这个运行标志。如果发现当前根本没有在运行它就直接抛出ProfilerNotRunningError而不是静默忽略。从 Python 解释器的源码视角来看disable()内部做的事情大致是def disable(self): if self._state 0: # 引起注意这里就是问题所在 raise ProfilerNotRunningError(Cannot stop profiling. No profiler is running.) # 正常停止采样...所以这个报错的本质就是一句话你的代码调用了disable()但此刻 profiler 并没有处于运行状态这个停止操作是不合法的。2.2 为什么创建了对象不等于“在运行”有人会问我都prof cProfile.Profile()把对象创建出来了为什么不算在运行这里要打个比方。Profile()创建对象相当于你买回来一台录像机摆在了桌子上。录像机本身是通电待机的但它没有在“录制”。什么时候算在运行呢是你按下“录制”按钮之后。对于 profiler 来说enable()就是那个“录制”按钮。只有enable()被调用过profiler 才真正挂载到 Python 解释器的内部钩子上开始记录每一次函数调用的入口和出口时间。之前的创建对象只是把录像机的电源接上了而已。这个报错告诉你的事故相当于你根本没有按过“录制”按钮却直接按了“停止录制”然后录像机跟你说“我没在录怎么停”3. 触发这个报错的几类典型代码我平时帮别人排查这个问题时见到的触发场景绝大多数集中在下面几种写法里。逐类做一个拆解。3.1 写了 enable 逻辑但实际没执行到这是最常见的一类代码结构上写着要开启 profiler但因为某种原因enable()那行代码没有真正执行。看这个例子import cProfile def do_something(): profiler cProfile.Profile() if should_profile: profiler.enable() # 这里的条件判断可能为 False do_long_task() profiler.disable() # 无条件执行于是报错如果should_profile是 False整个分析过程就不应该走。但 disable 放在外面无条件执行于是一个ProfilerNotRunningError就炸出来了。还有一种情况更容易忽略——异常打断。enable()执行了但后续的代码抛出了异常异常被外部 catch 住了disable()根本就没机会跑到profiler cProfile.Profile() profiler.enable() # 某个函数中途抛异常 do_work() # raise Exception profiler.disable() # 永远不会执行到这里内层没有 catch 的情况下disable()被跳过程序虽然不会立刻报ProfilerNotRunningError但如果外面还有一层try...finally的写法情况就会变得复杂。3.2 忘记调用 enable 直接调 disable这种属于纯手误。写完cProfile.Profile()后直接进入业务逻辑最后写一个disable()全程没有enable()import cProfile profiler cProfile.Profile() # 忘记调用 profiler.enable() long_task() profiler.disable() # 抛出 ProfilerNotRunningError这种代码在 IDE 里跑的时候报错信息一出来很多人还会愣一下我刚才明明创建对象了呀其实问题就是我前面说的——创建对象和启动采集是两码事。3.3 多次调用 disable 或重复 stop还有一种报错场景是在代码里对同一个 profiler 对象调用了两次disable()profiler cProfile.Profile() profiler.enable() long_task() profiler.disable() # 后续一些逻辑后又来一次 profiler.disable() # 第二次调用此时已经不在运行直接抛异常第一次disable()已经把运行标志置为 False 了第二次再调用这不就等于对一台已经停止录制的录像机再次按“停止”键吗理所当然会报错。3.4 enable 和 disable 作用在不同对象上这类坑藏得深一点。代码里创建了多个 Profile 对象但开启和关闭时拿的不是同一个profiler_a cProfile.Profile() profiler_b cProfile.Profile() profiler_a.enable() long_task() profiler_b.disable() # 开启的是 a关闭的是 b不报错才怪这种多对象交叉使用的情况在较复杂的脚本中偶尔会出现。特别是当代码是从别人那里改造来的或者多个函数各自维护了自己的 profiler 时很容易出现“关错对象”的问题。3.5 对同一个对象先 disable 后 enable 的混乱顺序还有一种写法就是把顺序搞反了。先调用disable()后调用enable()profiler cProfile.Profile() profiler.disable() # 还没 enable 过直接报错 profiler.enable() long_task()这种代码逻辑一看就很混乱但在重新组织代码时偶尔会犯这种错。令人意外的是有些人把它放进 try 块里时连异常本身都会被吞掉导致问题更隐蔽。4. 正确使用的标准姿势三种方案供直接抄知道触发场景后解决思路就很清晰了保证 enable 和 disable 严格成对出现并且顺序正确。下面提供三种我实际用过、并推荐过的写法直接抄就行。4.1 方案一try ... finally 包裹最推荐把disable()放在finally块里无论中间代码是否异常都能正常停止 profilerimport cProfile profiler cProfile.Profile() try: profiler.enable() long_task() # 你实际要分析的代码 finally: profiler.disable() # 无论是否异常到这里必然执行 stats pstats.Stats(profiler) stats.sort_stats(cumulative).print_stats(20)这个方案的优点在于即使long_task()中途抛出异常disable()也会因为finally的机制而执行。因为enable()是执行在try块外面的所以基本保证了“只要走到了 try 里面就一定 enable 过”。如果你希望更保险一点也可以把enable()也挪进try块的第一行try: profiler.enable() long_task() finally: profiler.disable()这样连“enable 是否执行成功”也被纳入管控范围。不过由于enable()本身很少抛异常两种写法在实践中等价。4.2 方案二提前开启用完停止如果 profiling 的作用域覆盖整个脚本推荐直接在脚本开头开启在脚本结尾再停import cProfile import pstats def main(): # 业务逻辑代码 ... # 其它函数调用 ... if __name__ __main__: profiler cProfile.Profile() profiler.enable() main() profiler.disable() stats pstats.Stats(profiler) stats.sort_stats(tottime).print_stats(30)这种写法适合“分析整个程序的运行性能”从main()入口开始采样直到结束。因为enable()和disable()同时位于最外层同一个代码块中没有中间状态所以不容易出错。4.3 方案三写一个上下文管理器优雅通用如果要分析多段代码或者想更干净地管理 profiler 生命周期可以把启动和停止逻辑封装成一个上下文管理器import cProfile import pstats from contextlib import contextmanager contextmanager def profiling(): profiler cProfile.Profile() profiler.enable() try: yield profiler finally: profiler.disable() stats pstats.Stats(profiler) stats.sort_stats(cumulative).print_stats(20) # 使用方式 with profiling(): long_task() another_task()这个上下文管理器能确保disable()总是被执行。同时由于with块结构清晰不容易出现“换行后忘了取消注释导致 enable 被跳过”这种低级错误。我还见过一些团队把这个profiling装饰器追加到函数定义上实现“自动分析某个函数的性能”核心逻辑和上面的上下文管理器大同小异这里不再扩写。5. 深挖一下为什么 Python 不自动处理这个情况有人可能会想Python 能不能在disable()时自动“假装没这回事”静默忽略掉这种非法状态毕竟很多代码对“停止一个没启动的服务”是非常宽容的。这个报告的抛出其实是有设计考虑的。对于 profiler 来说enable()和disable()都是开发者在调试代码时手动加上去的随意的静默忽略可能会掩盖真正的问题。举个例子如果你想让某段代码被分析但enable()实际上因为条件判断没执行你根本不知道分析没生效。此时disable()要是静默忽略并输出一份空结果一方面会让你误以为分析数据有效另一方面也会掩盖“enable 的触发条件有问题”这个事实。抛出异常的设计本质上是让开发者尽早发现问题而不是掩盖问题这是对性能分析正确性的重要保护。对于标准库而言ProfilerNotRunningError的设计遵循了 Fail Fast 的工程原则——在无法确定当前状态合法时用异常强制要求程序员解决问题而不是让它继续在错误状态下运行最后产出无意义甚至误导性的数据。6. 完整的排查清单直接从报错定位到问题如果你碰到这个报错按下面的步骤从快到慢排查。我一般也是这样给自己排错的顺序很重要。先确认代码中是否有 enable()全局搜索一下确认一下是否存在enable()的调用。哪怕调用了也确认它是否真的执行到了有条件判断、有提前 return、被异常打断都可能导致不了。确认 enable() 和 disable() 是否在同一作用域/同一对象上这两个方法必须作用于同一个Profile对象实例。如果有多个 profiler 变量检查是不是“张冠李戴”了。检查是否存在二次 disable()看看代码里是不是对同一个对象调用了两次disable()可以用 IDE 的查找功能也可以人工梳理一遍调用路径。检查是否存在分支导致顺序错乱比如if/else中一个分支 enable、另一个分支 disable或者try/except中 enable 在 try 里、disable 在 except 里这种结构特别容易导致状态不配对。用 try...finally 重构无论实际原因是什么强烈建议直接用 4.1 方案的try...finally结构替换裸的enable()/disable()。这样不管之前的问题是什么这种写法都能一劳永逸地规避掉。检查是否是在多线程环境下使用如果代码里有线程又恰好有多个线程同时启停同一个 profiler 对象那么竞态条件也可能导致这个报错。这种情况需要给 profiler 的启停加上锁或者干脆每个线程用独立的 profiler。7. 实操复盘一个真实案例的排查过程为了让大家更有体感我把一个好朋友的经历脱敏后写在这里。某天他在处理一段循环逻辑的代码时循环内部创建了 profiler对每次迭代做性能分析并且记录每次迭代的累计耗时import cProfile import pstats for i in range(10): profiler cProfile.Profile() profiler.enable() if i % 3 0: # 模拟一个耗时操作 for _ in range(1000000): pass profiler.disable() stats pstats.Stats(profiler) stats.print_stats(1)看了一下这段代码有三个问题点触发报错的核心在于i % 3 ! 0的时候enable()虽然调用了但本质上分析区间极短但真正导致ProfilerNotRunningError的是另一个隐蔽问题对于i 0时enable()执行后disable()正常对于i 1,2时enable()执行后disable()也正常。问题不出在这里。那真正报错的地方在哪呢注意看stats pstats.Stats(profiler)在循环里每次都会创建一个新的 Stats 对象但只在disable()之后创建理论上不存在直接报错的问题。他当时的实际错误其实是这样循环内enable()和disable()是成对的但循环外还有一个profiler.disable()。这个外层调用直接导致第二次disable()于是报错。这种“内外嵌套时有重复 disable”的情况就是前面 3.3 小节的典型。他实际的代码大致是profiler cProfile.Profile() for i in range(10): profiler.enable() ... profiler.disable() ... profiler.disable() # 多出来的一个现象就是循环内的每次disable()都好好的循环结束后最后一个disable()报错因为此时前一轮早已把状态置为 False 了。排查过程其实很简单看到报错后我先把所有disable()列出来逐个对照每个enable()很快就发现数量不配对。把多余的那个删掉运行就正常了。这类错误的排查思路核心就是列出所有 enable 和 disable 的调用点检查是否一一对应。8. 附带避坑经验一些相关的边角知识点平时处理 profiler 相关问题时还有一些零碎的坑这次一并整理出来。8.1 enable 和 run 不要混用cProfile.Profile对象有enable()/disable()方法同时模块层面还有cProfile.run()这种函数式入口。很多人会写出这种代码import cProfile prof cProfile.Profile() prof.enable() cProfile.run(long_task()) prof.disable() # 理论不报错但逻辑混乱这种代码不一定会触发ProfilerNotRunningError但逻辑上叠床架屋。cProfile.run()内部会自己创建一个 profiler 并自动启停跟外部手动启停的 profiler 是两套独立机制数据也分开。建议二者只选其一。8.2 装饰器场景下的状态管理有人喜欢自己写装饰器来给函数加性能分析比如import cProfile import pstats import functools def profile_func(func): functools.wraps(func) def wrapper(*args, **kwargs): profiler cProfile.Profile() profiler.enable() try: return func(*args, **kwargs) finally: profiler.disable() stats pstats.Stats(profiler) stats.sort_stats(cumulative).print_stats(10) return wrapper如果你要同时装饰多个函数要注意它们各自使用独立的Profile对象互不干扰。但如果你的意图是统计“整条调用链的总性能”装饰器就不太合适了因为每个被装饰的函数只关心自己那一段全局视角缺失。此时应该用上下文管理器包住整个调用链的入口。8.3 和 logging 结合时异常堆栈容易丢失有些老代码会这样写try: profiler.disable() except: pass为了不让程序崩溃把异常吞掉了。但如果后续要生成统计报告比如pstats.Stats(profiler).print_stats()在没有数据的情况下能得到的结果是空的看起来像“没问题”实际上 profiling 根本没生效。这也是一个隐性坑建议调试阶段不要把异常吞掉先让问题暴露出来。8.4 使用 pstats 时注意统计维度pstats.Stats支持按多种维度排序常用的有tottime函数自身的总耗时不含子调用和cumulative函数自身加所有子调用的累计耗时。分析性能瓶颈时这两个维度结合看才有意义。如果一个函数tottime很高说明瓶颈在它自身如果cumulative高但tottime低说明瓶颈在它的子调用里。只看一个维度很容易被误导。刚才提到的方法stats pstats.Stats(profiler) stats.sort_stats(cumulative).print_stats(20)其中的数字 20 表示只输出耗时前 20 行的函数数据量较大时这个限制很有用。9. 常见问答速查表遇到问题直接对号入座症状可能原因解决方案第一次调用 disable 就报 ProfilerNotRunningError根本没有执行 enable()补上 enable()或确认 enable() 是否被条件分支跳过第二次调用 disable 报错重复停止同一个 profiler检查调用点删除多余的 disable()多个 profiler 变量交叉启停报错enable 和 disable 作用于不同对象统一使用同一个 Profile 变量对象try/except 中 enable 在 try 内、disable 在 except 内异常在 enable 前抛出或 try 内还有其它异常路径改用 try/finally 保证 disable 总执行多线程中某个线程突然报错多个线程共享了同一个 profiler 对象每个线程独立创建 Profile 对象或加锁保护启停操作程序没报错但统计结果为空enable 的触发条件不满足异常被吞去掉吞异常逻辑检查 enable 是否真的执行10. 最后分享一个小技巧开发时怎么快速定位这类状态问题根据我自己的经验在排查这类启停状态问题时有一种调试办法特别高效在 enable 和 disable 前后各打一行调试日志记录当前时间和调用点栈。别小看这个土办法它能帮你快速看清这两个关键动作真实的执行顺序。import cProfile import traceback profiler cProfile.Profile() print(before enable, state:, profiler._state if hasattr(profiler, _state) else unknown) profiler.enable() try: long_task() finally: print(before disable) profiler.disable() print(after disable)如果是profile.Profile内部属性名可能不同如果访问不到具体的私有状态打日志看调用顺序就够了。这种方法特别适合排查那些“明明写了 enable 却好像没执行”的诡异场景——日志一打出来执行顺序一目了然。还有一个已经过验证的有效做法在 Python 交互式环境中最小化复现这个问题把代码缩减到最短几行确认基础行为正确后再往原代码里迁移这样比起直接在大型项目里猜测要高效得多。ProfilerNotRunningError这个报错理论层面很浅本质上就是 enable 和 disable 没配对。但正因为简单才更容易在写着写着代码的时候被忽略。这种小坑排起来花费的时间往往比大故障还多。希望这篇内容能帮你少走一段弯路至少在下次面对这个报错时第一反应不是“见鬼了”而是“我去看看 enable 跑哪去了”。