structlog多日志器配置全攻略

本文深入解析了如何在 structlog 中实现多日志器的差异化配置——由于 structlog 不支持对已有 logger 实例调用 `.configure()` 进行局部修改，官方推荐使用 `structlog.wrap_logger()` 手动封装独立的处理器链，从而为不同用途（如 JSON 输出、彩色控制台、文件写入等）创建完全解耦、互不影响的日志器实例；该方法不仅规避了全局配置的限制，还完美契合 structlog 函数式、无状态的核心设计哲学，是构建灵活、可维护日志系统的最佳实践。

structlog 本身不支持对已获取的 logger 实例调用 `.configure()` 进行局部配置，但可通过 `structlog.wrap_logger()` 手动封装不同处理器链，实现多日志器差异化输出。

在 structlog 中，structlog.configure() 是全局生效的设置，影响所有后续通过 structlog.get_logger() 创建的日志器。因此，直接对 logger1.configure(...) 和 logger2.configure(...) 调用不仅无效（会抛出 AttributeError），也违背其设计哲学——structlog 的核心是无状态的处理器链（processor pipeline），而非传统 logger 对象的状态管理。

✅ 正确做法是使用 structlog.wrap_logger()：它允许你为任意可调用对象（如 print、logging.getLogger() 或自定义函数）注入一组专属的 processors，并返回一个具备完整 structlog 接口（如 .info(), .error()）的绑定日志器（bound logger）。

下面是一个典型示例：

import structlog

# 定义两组不同的处理器
processors1 = [
    structlog.stdlib.filter_by_level,
    structlog.stdlib.add_logger_name,
    structlog.stdlib.add_log_level,
    structlog.stdlib.PositionalArgumentsFormatter(),
    structlog.processors.TimeStamper(fmt="iso"),
    structlog.processors.JSONRenderer(),  # 输出 JSON
]

processors2 = [
    structlog.stdlib.filter_by_level,
    structlog.processors.format_exc_info,
    structlog.processors.CallsiteParameterAdder(
        {
            structlog.processors.CallsiteParameter.FILENAME,
            structlog.processors.CallsiteParameter.FUNC_NAME,
        }
    ),
    structlog.dev.ConsoleRenderer(),  # 彩色控制台输出
]

# 封装两个独立日志器（均基于同一底层目标，例如 print）
logger1 = structlog.wrap_logger(
    print,
    processors=processors1,
    context_class=dict,
    logger_factory=structlog.PrintLoggerFactory(),
)

logger2 = structlog.wrap_logger(
    print,
    processors=processors2,
    context_class=dict,
    logger_factory=structlog.PrintLoggerFactory(),
)

# 使用示例
logger1.info("this goes as JSON", user_id=42)
logger2.error("this appears in dev-friendly console format", error_code="E001")

⚠️ 注意事项：

• wrap_logger() 返回的是 全新、完全独立 的日志器实例，彼此间处理器、上下文、序列化方式互不影响；
• 若需与 Python 标准库 logging 深度集成（如写入文件或 syslog），可将 logging.getLogger("name") 作为第一个参数传入 wrap_logger()，并搭配 structlog.stdlib.LoggerFactory()；
• 不要混用 get_logger() 和 wrap_logger() 创建的日志器来共享配置——前者依赖全局配置，后者完全自治；
• 所有 wrap_logger() 创建的日志器默认不继承全局 configure() 设置，确保了彻底解耦。

总结：当需要多个语义/格式/目的地各异的日志通道时，structlog.wrap_logger() 是 structlog 官方推荐且最灵活的解决方案。它将“配置”从全局静态行为转变为日志器级别的构造时声明，契合函数式、不可变的设计理念。

今天关于《structlog多日志器配置全攻略》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！