Python代码运行时间怎么查？3招让你告别瞎猜

写Python最怕什么？不是报错，而是代码跑得慢得像蜗牛，你却不知道问题出在哪。上周我同事优化一个数据处理脚本，凭感觉改了两天，结果只快了5%。后来用对工具一测，发现80%时间都耗在一个隐藏的死循环上。这种"盲人摸象"的优化，浪费时间还打击信心。其实查代码运行时间有门道，今天就掰开揉碎讲清楚。 最硬核的办法是用time模块，简单粗暴但贼好用。在代码开头塞个`start = time.time()`，结尾来个`end = time.time()`，一减就是总耗时。不过这只是入门玩法，真想精准定位"哪行代码是拖油瓶"，得请出cProfile这位大神。它是Python自带的性能分析器，不用安装，直接`python -m cProfile your_script.py`，哪个函数调用多少次、占多少CPU，清清楚楚列成表。我习惯加个`-s cumulative`参数，按累计时间排序，罪魁祸首直接排到最前面，连狡辩的机会都没有。

但工具再牛，也得会用才行。很多人踩过一个坑：在IDE里直接运行和命令行跑，时间能差出好几倍。为啥？IDE的调试模式、变量监控都在偷偷吃资源。还有的人测性能时开着音乐、下载着电影，测出来的数据跟闹着玩似的。更隐蔽的是Python的缓存机制，第一次运行慢得离谱，第二次飞快，这不是你优化有功，是CPU在偷懒。所以正经测时间，至少跑三轮取平均，关掉所有无关程序，这才是科学态度。

说到实战，有个案例特别典型。我之前处理一个10GB的日志文件，用pandas直接读，内存爆炸还慢。用cProfile一测，发现`read_csv`占了90%时间。改用分块读取`chunksize`，时间从20分钟砍到2分钟。还有一次，递归函数写得爽，结果n=1000就栈溢出，改成迭代配合`timeit`模块反复测试，才找到最稳的平衡点。这些经验光靠猜是猜不出来的，数据面前人人平等。

你平时怎么测Python代码速度的？是print一堆时间戳硬怼，还是已经用上高级工具了？评论区聊聊，说不定你的笨办法比我的还香。要是这篇对你真管用，点个赞让我知道，下期咱们深挖"怎么让Python跑得比C还快"——没错，真的有办法。