可拔插式日志输出是通过函数类型（如 func(string, ...any)）动态切换日志行为，支持运行时条件判断、上下文增强与降级，需用原子操作或互斥锁安全替换，且函数不自带状态，依赖显式传参或闭包捕获上下文。
什么是可拔插式日志输出？
它不是指“换一个 logger 实例”，而是让日志行为（比如是否打印、打到哪里、加不加 traceID）能在线上运行时动态切换，且不侵入业务代码。Golang 里最轻量、最可控的方式，就是用函数类型封装日志行为，而不是依赖 interface{} 或反射。
func(string) 和 func(string, ...any) 哪个更实用？
选后者。业务日志几乎总是带格式化参数，比如 log.Info("user %s login at %v", userID, time.Now())。如果只定义 func(string)，你就得提前拼好字符串——这会丢失原始参数，无法做延迟格式化（比如日志被禁用时跳过 sprintf 开销），也妨碍采样或结构化处理。
- 推荐签名：
type LogFunc func(string, ...any) - 实际使用时，把
fmt.Printf、zap.Sugar().Infof、甚至空函数func(...){}都能直接赋值给该类型变量 - 注意：不要用
func(...interface{})，Go 泛型普及后它已无优势，且和标准库日志函数签名不一致，容易在传参时漏掉...导致 panic
如何安全替换正在运行的 logger 函数？
直接赋值 logFunc = newLogger 看似简单，但并发写入时可能让某次调用拿到半新半旧的函数值（尤其在 Go 1.20 之前）。必须用原子操作或互斥锁保护。
- 最简方案：用
sync/atomic+unsafe.Pointer存储函数指针（需确保函数类型完全一致） - 更稳妥方案：包一级定义
var logMu sync.RWMutex和var logImpl LogFunc，读日志时只logMu.RLock()，换实现时logMu.Lock() - 切忌在 HTTP handler 里频繁调用替换函数——这不是配置热更新，而是行为切换，应限定在初始化或运维指令触发时
为什么不用 io.Writer 而坚持用函数类型？
因为 io.Writer 只能处理字节流，你没法在写入前决定“这条要不要记”“要不要加 caller 信息”“要不要发 Kafka”。而函数类型天然支持：
立即学习“go语言免费学习笔记（深入）”；
- 条件判断：
if shouldLog() { f(msg, args...) } - 上下文增强：
f("[trace:%s] "+msg, traceID, args...) - 错误重试或降级：
if !writeToDisk(msg) { writeToMemoryBuffer(msg) }
一旦你发现需要对日志内容做逻辑分支，io.Writer 就得套一层 wrapper，而函数类型一步到位。
真正容易被忽略的是：函数类型本身不携带状态，所有上下文（如 level、caller skip、采样率）必须显式传入或闭包捕获。别指望靠“换一个函数”就自动继承全局配置——那是设计漏洞，不是灵活性。
