17370845950

调试时临时验证用print，正式场景必须用logging；print适合开发初期快速探路，logging提供分级、定向、格式化和可维护的日志能力。

调试时该用 print 还是 logging，关键看阶段和需求：临时快速验证用 print 更轻量；需要留存、分级、控制输出或上线后仍需可观测性时，必须用 logging。

什么时候直接用 print 就够了

print 适合开发初期的“探路式”调试——比如刚写完一个函数，想立刻确认输入输出是否符合预期，或者快速定位某行代码有没有执行到

• 无需配置，一行就出结果，改完删掉也方便
• 配合 f-string（如 print(f"x={x}, type={type(x)}")）能清晰看到变量值和类型
• 在 Jupyter 或交互式环境里，print 的即时反馈比配置 logger 更顺手

为什么 logging 在多数正式场景更可靠

logging 不是“高级版 print”，而是为可维护性设计的日志系统。它解决的是 print 天然不具备的能力：

• 级别控制：用 logger.debug() 记细节，logger.warning() 标异常倾向，logger.error() 报错误，上线时可一键关闭 debug 日志，不影响性能
• 输出定向：日志既能打到控制台，也能自动写入文件，还能发到远程服务，print 只能 stdout/stderr
• 格式统一：自带时间戳、模块名、行号（如 2025-06-15 10:23:41,123 - mymodule.py:42 - INFO - 数据加载完成），排查问题时不用再手动拼接
• 避免误提交：团队协作中，print 很容易被遗忘并随代码上线，而 logging 默认级别设为 WARNING 以上时，debug 日志天然静默

一个务实的过渡建议

不必从第一行代码就上完整 logging 配置。可以这样渐进使用：

• 先用 logging.basicConfig(level=logging.DEBUG) 快速启用基础日志，体验和 print 差不多的写法（logging.debug("x=%r", x)）
• 把频繁修改/删除的 print 替换为 logging.debug()，保留逻辑但获得可开关性
• 当项目结构变复杂，或需要区分模块日志时，改用命名 logger：logger = logging.getLogger(__name__)，避免全局污染
• 上线前，在入口处设置 logging.basicConfig(level=logging.WARNING)，debug 和 info 日志自动消失，无需逐行删 print

别忽略的细节

用 logging 时几个易错点：

• 不要用字符串拼接传参：写 logging.debug("value=%s", x)，而不是 logging.debug("value=" + str(x))。前者在日志关闭时不会计算 str(x)，更高效
• 避免在日志里调用可能抛异常的函数：比如 logging.info("len=%d", len(obj))，如果 obj 不支持 len()，日志还没打出就崩溃了
• DEBUG 级别日志默认不显示：运行脚本时若没设 level，只看到 WARNING 及以上，记得加 basicConfig(level=logging.DEBUG)