Go 标准库的 log 包轻量简洁，但缺乏日志级别控制、结构化输出、上下文支持、滚动文件、异步写入等现代日志功能，适用于简单场景；生产环境推荐使用 Logrus、Zap 等成熟第三方库。
go 标准库的 `log` 包轻量简洁，但缺乏日志级别控制、结构化输出、上下文支持、滚动文件、异步写入等现代日志功能，适用于简单场景；生产环境推荐使用 logrus、zap 等成熟第三方库。
Go 的标准库 log 包设计哲学是“小而专”——它提供了基础的日志输出能力（如时间戳、前缀、调用位置），代码仅约 300 行，无外部依赖，非常适合教学、脚本或极简服务。然而，在中大型生产系统中，其固有局限会显著制约可观测性与运维效率。以下是关键限制及应对思路：
? 1. 缺乏原生日志级别（Level）语义
log 包不区分 INFO/WARN/ERROR/DEBUG，所有日志统一处理。虽可通过多个 log.Logger 实例模拟（例如分别封装不同前缀和输出目标），但需手动管理、无内置过滤机制，也难以全局开关 DEBUG 日志：
// 手动模拟日志级别（不推荐用于复杂项目）
infoLog := log.New(os.Stdout, "[INFO] ", log.LstdFlags)
warnLog := log.New(os.Stderr, "[WARN] ", log.LstdFlags | log.Lshortfile)
errorLog := log.New(os.Stderr, "[ERROR] ", log.LstdFlags | log.Lshortfile)
infoLog.Println("user logged in")
warnLog.Println("cache miss, falling back to DB")
⚠️ 注意：这种方式无法动态调整级别，也不支持结构化字段（如 {"user_id": 123, "duration_ms": 42}）。
? 2. 输出目标扩展性弱，无开箱即用的滚动策略
虽然可通过 log.SetOutput() 或 log.New() 将日志重定向到 *os.File，但文件滚动（rolling）、按大小/时间切分、自动归档、压缩等功能需完全自行实现。例如：
// 基础文件日志（无滚动！）
f, _ := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
log.SetOutput(f)
defer f.Close()
若需按天滚动，须引入定时器、文件检查、重命名逻辑——而 Logrus + rotatelogs 或 Zap 的 lumberjack 可一行配置完成。
? 3. 无结构化日志与上下文支持
标准 log 仅支持格式化字符串（log.Printf("user %s failed: %v", name, err)），无法原生输出 JSON 或键值对。调试时难以被 ELK、Loki 等日志平台高效解析。同时，无法便捷注入请求 ID、trace ID 等上下文信息。
? 4. 同步阻塞，无异步/缓冲能力
所有日志写入均为同步 I/O，高并发下易成性能瓶颈。第三方库（如 Zap）提供 Logger.WithOptions(zap.BufferedWriteSyncer(...)) 或异步 wrapper，显著降低日志对主业务的影响。
✅ 何时可继续用标准 log？
- CLI 工具、一次性脚本、单元测试辅助日志
- 容器化部署且遵循 12-Factor 原则：直接输出到
os.Stdout/os.Stderr，由容器运行时（Docker/K8s）或日志代理（Fluentd、Filebeat）统一收集与路由 - 示例（推荐做法）：
// 不写文件，交由基础设施处理 log.SetOutput(os.Stdout) // 或 os.Stderr 用于错误 log.Println("server started on :8080")
? 生产建议：平滑迁移至专业日志库
- Logrus：API 友好，插件丰富（JSON 格式、Hook、自定义 Level），适合快速落地（注意：已归档，新项目建议选 Zap）
- Zap（Uber）：高性能、结构化、零内存分配（Core 层），业界生产首选，学习曲线略高但长期收益大
- Zerolog（Cloudflare）：极致性能 + 链式 API，纯函数式风格
? 总结：
log包不是“不好”，而是定位不同——它是日志的“汇编语言”。当需求超出fmt.Fprintf(os.Stderr, ...)的范畴时，选择成熟的日志框架不是过度工程，而是对可维护性与可观测性的必要投资。
