print 是临时调试工具，log 是并发安全、带时间戳和可重定向的正式日志设施；前者无级别、无格式、不线程安全，后者支持元信息、输出控制与基础同步机制。
print 和 log 看起来都是“打日志”，但它们根本不是一回事——别拿 print 当日志用，也别指望 log 像 print 那样轻量。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
为什么不能用 print/println 替代 log
print 是语言内置调试辅助函数，不是日志设施：
- 它输出到 stderr，但不加锁，**并发写会乱序甚至截断**
- 不支持时间戳、文件名、行号等元信息，也没办法重定向到文件
- 无法打印结构体、切片等复合类型，只会输出地址（比如 &{0xc000010240}），而 log.Printf 输出的是实际值 [1 2 3]
- 参数不会逃逸到堆，看似省内存，但代价是丧失可读性和调试能力——你没法在日志里看到真实数据
- 没有线程安全机制，多 goroutine 同时调用 print 可能导致输出粘连（如两行日志挤成一行）
log 默认输出到 stderr，但比 fmt.Println 多了什么
log 包默认也写 stderr，但它自带并发安全锁，且预设了基础格式化能力：
- 每条输出自动带时间戳（2026/06/30 10:50:12），可通过 log.SetFlags() 扩展，例如：log.SetFlags(log.LstdFlags | log.Lshortfile) → 加上 main.go:12
- 支持 log.Printf 格式化，和 fmt.Printf 行为一致，但底层已做同步保护
- log.SetOutput(f) 可轻松切换到文件，且所有后续调用（包括第三方库中未重定向的 log.Print）都会跟着走——这点常被忽略，导致日志“消失”
- 它不是简单包装 fmt，而是封装了 writer + mutex + prefix + flags 的完整小系统
log.Fatal 和 log.Panic 在 HTTP handler 里为什么是危险操作
它们不是“严重错误日志”，而是控制流终结器：
- log.Fatal("xxx") 等价于 log.Print("xxx"); os.Exit(1) → 整个进程退出，HTTP server 直接挂掉
- log.Panic("xxx") 等价于 log.Print("xxx"); panic("xxx") → 若没被 recover 捕获，同样崩溃
- 在 handler 中应返回 error，由中间件或路由层决定是否记录 + 终止；直接调 log.Fatal 就像在电梯里拔电源——不是修故障，是炸楼
- 即便在 main 函数里用 log.Fatal，也要确认：这真的是不可恢复的启动失败（如配置加载失败），而不是运行时业务错误
什么时候该用 fmt.Print*，什么时候必须用 log
区分依据不是“要不要换行”，而是“是否需要可运维、可追溯、可重定向的输出”：
- 临时调试、脚本快速验证、CLI 工具的用户可见输出 → 用 fmt.Println（输出到 stdout，符合 Unix 哲学）
- 服务内部状态、错误追踪、后台任务进度、需写入文件或转发到日志收集系统 → 必须用 log 或更专业的库（如 zap）
- print 仅建议出现在极早期 bootstrapping 阶段（比如 init 函数里检查环境变量），且上线前必须删掉——它不属于任何可观测性体系
- 注意：log 不支持日志级别（Info/Debug/Error），如果项目需要分级，要么手动拼前缀（log.Printf("[ERROR] %s", err)），要么换库；别硬凑
真正容易被忽略的点是：标准 log 库没有上下文绑定能力。你在 handler 里生成了一个 traceID，想让它自动附在每条日志前？做不到。要么每条都手动传，要么换 zerolog 或 zap。这个缺口，往往等到线上查问题时才意识到。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
