调试时临时验证用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 -
格式统一：自带时间戳、模块名、行号（如
2024-06-15 10:23:41,123 - mymodule.py:42 - INFO - 数据加载完成），排查问题时不用再手动拼接 -
避免误提交：团队协作中，
print很容易被遗忘并随代码上线，而 logging 默认级别设为 WARNING 以上时，debug 日志天然静默
一个务实的过渡建议
不必从第一行代码就上完整 logging 配置。可以这样渐进使用：
立即学习“Python免费学习笔记（深入）”；
- 先用
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)
