来源：网络

你有没有遇到过这种情况？代码跑着跑着突然崩了，满屏幕的print输出根本找不到哪里出了问题。你往文件里塞了几十个print("here"), print("here2"), print("debug 3"), 结果真正报错的那行代码被淹没在几百行输出里，你还得一行行翻找，眼睛都看花了。

我曾经也是这样。刚学Python那会儿，一遇到bug就疯狂print，就像在黑夜里用手电筒找东西，照到哪里看到哪里。直到后来学会了Python自带的logging模块，才发现原来记录程序运行状态可以这么优雅——就像给代码装了一个行车记录仪，什么时候出了什么事，自动分类记录，一目了然。

今天这篇文章，我就把我这几年用logging踩过的坑、总结出来的经验，一次性分享给你。不用背复杂的文档，记住这3个核心用法，你就能告别满屏print的尴尬，成为更专业的开发者。

为什么print不够用了

先说一个残酷的事实：print不是给你调试用的，它是给用户看的。你用print调试，会遇到这些经典场景：

第一，所有输出都是一个级别。你想看一点调试信息，结果程序的常规输出、警告信息、报错信息全混在一起，根本分不清哪条重要。

第二，格式乱七八糟。print出来的东西没有时间、没有文件位置、没有函数名，万一程序崩溃了，你都不知道那条输出是哪里打印的。

第三，上线前还得一个个删print。删漏一个，用户就能在你的控制台看到"debug 233"这种奇怪的东西，要多尴尬有多尴尬。

而logging就是为了解决这些问题而生的。它有五个级别：DEBUG（调试）、INFO（常规信息）、WARNING（警告）、ERROR（错误）、CRITICAL（严重错误）。你可以按级别过滤，想看调试信息就只看DEBUG，上线后只看ERROR以上级别，非常灵活。

用法一：一行代码开启日志记录

logging最基础的用法只需要三行代码：

就这么简单。basicConfig()会自动帮你配置好日志处理器，让日志输出到控制台。level参数设置了日志的最低级别，这里设成INFO，意味着DEBUG级别的日志不会显示，INFO及以上级别的会显示。

如果你想调试程序，把level改成logging.DEBUG，就能看到所有调试信息。等程序上线了，再改成logging.ERROR，只显示错误，控制台立马清爽。

用法二：自定义格式，一目了然

print最大的问题就是格式太简陋。logging可以自定义输出格式，告诉你这条日志是什么时候、在哪个文件、第几行、什么函数里产生的：

运行结果会是这样：

看到没？时间、文件名、行号、函数名、日志级别、消息，全部都有。如果程序出了问题，你一眼就能定位到具体位置。

常用的格式字段有这些：

用法三：输出到文件，永久保存

print只能往控制台输出，程序一关日志就没了。logging可以直接写到文件里，永久保存：

这样日志就会自动写到app.log文件里，你可以随时查看历史记录，甚至可以设置日志轮转，让日志文件超过一定大小时自动创建新文件。

文件和控制台同时输出也很简单，稍微复杂一点的配置就能做到：

新手容易踩的坑

最后说几个新手用logging最容易踩的坑：

第一坑：basicConfig只能调用一次。如果你在程序里调用两次basicConfig，第二次会没效果。所以在程序入口调用一次就行了。

第二坑：root logger的坑。如果你只是简单用logging.info()，实际上用的是root logger。如果你的程序里有第三方库也用了logging，可能会混在一起。大型项目最好创建自己的logger。

第三坑：格式化字符串用懒加载。不推荐这样写：logging.info(f"当前值是{value}")，推荐这样写：logging.info("当前值是%s", value)。后者只在真正要输出日志的时候才格式化字符串，性能更好。

写在最后

logging是Python标准库的一部分，不需要安装任何第三方包。刚开始可能觉得比print麻烦，但当你习惯了之后，你会发现调试代码轻松多了。

一句话总结：开发阶段设成DEBUG看细节，上线之前设成ERROR保清爽，加上格式化标签，代码一搜就定位。

你平时调试代码还在用print吗？还是觉得logging太麻烦不想学？或者你已经有了一套自己的调试方法？评论区聊聊，看看大家都是怎么调试代码的。

长按或扫描下方二维码，免费获取 Python公开课和大佬打包整理的几百G的学习资料，内容包含但不限于Python电子书、教程、项目接单、源码等等
▲扫描二维码-免费领取