Structlog中logger.msg与info、debug日志方法的差异及适用场景

先讲两者最本质的差异：info/debug/warning这类带级别的方法，是Structlog对齐Python标准logging库设计的封装，调用时会自动给日志事件绑定对应的level字段，方便后续按日志级别做过滤、分流、告警；而logger.msg是不带任何预设级别属性的通用日志输出方法。

logger.msg的核心优势 #

• 灵活度更高：不会强制注入默认的level字段，你可以根据业务需要自定义任意分类标签，甚至完全不添加级别相关字段，不会被框架默认的级别过滤规则拦截。
• 性能开销更低：带级别的方法调用时会先执行级别注入、全局级别校验逻辑，只有校验通过才会走后续输出流程；msg直接跳过了这层默认逻辑，调用链路更短，高并发、大日志量场景下性能损耗更小。
• 输出确定性强：只要触发msg调用就会执行输出逻辑，完全不受全局日志级别配置影响，不会出现因为日志级别设得太高导致日志被吞的问题。

适合使用logger.msg的场景 #

• 短生命周期脚本/CLI工具场景：这类工具通常不需要做复杂的日志级别分流，所有日志都需要直接输出给用户看，用msg写起来更直接，也不用额外调整全局日志级别配置。
• 本地调试打临时日志：开发时临时加的调试日志不需要走正式的级别过滤逻辑，用msg可以确保日志一定会打印，不会因为全局配置是INFO级别就看不到调试内容，调试完删掉即可。
• 自定义日志分类体系的场景：如果你不想用标准库默认的debug/info/warning/error分级，要自己实现审计日志、埋点日志、链路追踪日志这类特殊分类，用msg可以自由绑定自定义的分类字段，不会被默认的level字段规则限制。
• 高性能要求的高频日志场景：比如流量网关、数据处理流水线这类每秒要输出上千上万条日志的场景，且这类日志不需要按级别过滤（比如全量采集的访问日志、逐行处理的进度日志），用msg能减少不必要的性能损耗。

注意：如果你的日志最终要对接到Python标准logging库、或者接入依赖level字段做筛选告警的日志系统（比如ELK、各类云厂商日志服务），不要用msg输出正式业务日志，否则会因为缺失标准级别字段导致日志无法被正确分类、触发告警规则。

内容的提问来源于stack exchange，提问作者Guido