Slog如何同時輸出到控制臺和文件？MultiHandler提案或將終結重復造輪子
自 log/slog 在 Go 1.21 中引入以來，一個常見的需求始終困擾著開發者：如何將日志同時發送到多個目的地，并為每個目的地設置不同的日志級別？盡管社區已涌現出 samber/slog-multi 等優秀的三方庫，但關于“標準庫是否應原生支持”的討論從未停止。最近，一項編號為 #65954 的提案，建議在 log/slog 中加入 MultiHandler，獲得了 Go 官方的 [likely accept] 評級。本文將帶您回顧該提案從被質疑到被接受的全過程，深入探討其背后的設計權衡。
背景：一個普遍而又棘手的需求
在實際生產環境中，日志往往需要被送往多個地方：
- 控制臺（stdout）：用于開發和調試，通常需要 DEBUG 級別的詳細信息。
- 本地文件：用于歸檔和追溯，可能需要 INFO 級別以上的日志。
- 遠端日志服務（如 ELK, Loki,VictoriaLogs等）：用于聚合和告警，可能只關心 ERROR 級別的日志。
然而，log/slog 的核心設計是一個 Logger 對應一個 Handler。雖然 io.MultiWriter 可以將相同格式、相同級別的日志寫入多個 io.Writer，但它無法滿足不同目的地、不同級別這一核心需求。
這導致許多開發者不得不自行實現 slog.Handler 來“扇出”（fan-out）日志，或者引入第三方依賴。正如提案者 lxl-renren 和多位評論者所指出的，這是一個非常普遍的場景。
從“不需要”到“值得擁有”的轉變
提案初期，Go 團隊成員 jba (Jonathan Amsterdam) 和 seankhliao 對其必要性提出了質疑，核心論點是：
- 社區已有解決方案：像 samber/slog-multi 這樣的庫已經很好地解決了問題。
- 實現相對簡單：開發者可以自己編寫一個 multiHandler 來實現。
- 避免增加標準庫維護負擔：Go 團隊對向標準庫添加新 API 持非常謹慎的態度。
然而，隨著討論的深入，社區的聲音和更多場景的出現，逐漸改變了 Go 團隊的看法。
- OpenTelemetry 集成：有開發者指出，當應用需要同時將日志發送到 stdout 和 OpenTelemetry Collector 時，MultiHandler 幾乎成了“剛需”。
- 依賴問題：還有開發者認為，僅僅為了一個功能而引入一個帶有額外依賴（有時甚至是不必要的測試依賴）的第三方庫，違背了 Go 崇尚簡約的哲學。
- 實現的微妙之處：甚至有開發者反駁了“實現簡單”的觀點，認為 slog.Handler 的正確實現存在許多“坑”（footguns），普通開發者未必能一次寫對，尤其是在處理 WithAttrs 和 WithGroup 的狀態傳遞時。
- 先例與慣例：社區成員指出，標準庫中已經存在 io.MultiReader 和 io.MultiWriter 這樣的先例，為 slog 提供一個 MultiHandler 符合語言的內在一致性。
Filippo Valsorda 的“三復制代碼”
在討論中，Go 安全負責人、核心開發者 Filippo Valsorda (@FiloSottile) 的評論成為了一個重要的轉折點。他分享了自己在三個不同項目中都復制粘貼了的 multiHandler 實現，并直言：“代碼量太少，不值得為此增加一個依賴。”
這段代碼堪稱 slog.Handler 實現的典范，簡潔而完整：
type multiHandler []slog.Handler
func MultiHandler(handlers ...slog.Handler) slog.Handler {
return multiHandler(handlers)
}
func (h multiHandler) Enabled(ctx context.Context, l slog.Level) bool {
for i := range h {
if h[i].Enabled(ctx, l) {
returntrue// 只要有一個 handler 需要，就啟用
}
}
returnfalse
}
func (h multiHandler) Handle(ctx context.Context, r slog.Record) error {
var errs []error
for i := range h {
// 在 Handle 內部再次檢查 Enabled，確保日志只發給需要的 handler
if h[i].Enabled(ctx, r.Level) {
// 克隆 Record 以防 handler 修改，影響后續 handler
if err := h[i].Handle(ctx, r.Clone()); err != nil {
errs = append(errs, err)
}
}
}
return errors.Join(errs...) // 合并所有 handler 的錯誤
}
func (h multiHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
handlers := make([]slog.Handler, 0, len(h))
for i := range h {
handlers = append(handlers, h[i].WithAttrs(attrs))
}
return multiHandler(handlers)
}
func (h multiHandler) WithGroup(name string) slog.Handler {
handlers := make([]slog.Handler, 0, len(h))
for i := range h {
handlers = append(handlers, h[i].WithGroup(name))
}
return multiHandler(handlers)
}Filippo 的分享有力地證明了：這確實是一個普遍存在、實現固定、但自己寫又有點麻煩的“最佳實踐”代碼片段。將其標準化，可以避免社區無數次地“重復造輪子”。
最終提案：一個簡單、順序、可預測的 MultiHandler
最終，在充分吸取了社區的意見后，jba 轉變了看法，并親自提出了最終的 API 提案，該提案目前已被標記為 [likely accept]：
// MultiHandler returns a handler that invokes all the given Handlers.
// Its Enable method reports whether any of the handlers' Enabled methods return true.
// Its Handle, WithAttr and WithGroup methods call the corresponding method on each of the enabled handlers.
func MultiHandler(handlers ...Handler) Handler在討論中，團隊還明確了幾個重要的行為特性：
- 順序執行：MultiHandler 將依次、同步地調用每一個 handler，類似于 io.MultiWriter。
- 錯誤處理：與 io.MultiWriter 在遇到第一個錯誤時就停止不同，MultiHandler 將會繼續執行所有的 handler，并最終通過 errors.Join 返回所有遇到的錯誤。這對于日志場景更為合理，因為一個 handler（如遠程服務）的失敗不應阻止日志被寫入另一個更可靠的 handler（如 stderr）。
- 不處理并發：標準庫版本將不會內置復雜的異步、批處理或超時邏輯。這些高級功能被認為設計自由度太大，更適合由社區的第三方庫來實現和探索。
小結
slog.MultiHandler 的提案演進過程，是 Go 標準庫發展哲學的一次完美體現。它始于一個看似“社區可以自己解決”的問題，但通過社區的廣泛反饋和真實場景的展示，最終證明了將其標準化的價值：為最普遍的需求提供一個簡單、可靠、零依賴的解決方案，同時為更復雜的需求留出空間，讓社區生態去創新。
對于廣大的 Go 開發者而言，這無疑是個好消息。在不久的將來，我們或許就能告別為多目標日志而編寫的那些重復代碼或引入的微小依賴，享受到標準庫帶來的便利和統一。這正是 Go 語言持續改進、不斷提升開發者體驗的魅力所在。
資料鏈接：https://github.com/golang/go/issues/65954
