Go中用log.SetFlags控制日志前缀：设0可去所有前缀但需手动换行并确保SetOutput(os.Stdout)；去时间戳应排除Ldate；调试用Lshortfile；CLI中用户提示用fmt，错误用log.Printf配SetFlags(0)和SetOutput(os.Stderr)。
如何用 log.SetFlags 控制日志前缀格式
Go 默认日志会在每行开头加时间戳和文件位置，但命令行工具通常不需要这些冗余信息，尤其在管道输出或与其它命令组合时容易破坏结构化数据。关键在于调用 log.SetFlags 修改标志位。
常见错误是直接写 log.SetFlags(0)，结果发现日志完全不输出——其实是因为 Go 默认还启用了 log.LstdFlags，而 0 会关闭所有标志，包括最基本的换行和缓冲刷新逻辑（底层依赖 os.Stderr 的行为）。
- 只去掉时间戳：用
log.SetFlags(log.Lshortfile | log.Ldate)→ 错，Ldate就是时间戳，应排除 - 干净输出（仅内容）：推荐
log.SetFlags(0)+ 确保log.SetOutput(os.Stdout)，再手动加换行（因为0会禁用自动换行） - 保留文件名+行号调试用：用
log.SetFlags(log.Lshortfile)，注意它默认仍带冒号和空格，如main.go:23:
为什么 log.Printf 在 CLI 中常被误用
命令行日志不是服务端日志，log.Printf 的默认行为（输出到 stderr、带前缀、不 flush）在交互式场景下容易造成输出顺序错乱或缓冲滞留。比如用户输入后立刻显示提示，但日志卡在缓冲区没出来。
更合适的做法是区分用途：
立即学习“go语言免费学习笔记（深入）”；
- 用户可见提示（如“正在下载…”）：直接用
fmt.Fprintln(os.Stdout, ...)，避免日志系统干扰 - 调试/错误追踪：用
log.Printf，但提前设好log.SetOutput(os.Stderr)和log.SetFlags(0) - 严重错误退出前的日志：用
log.Fatalln，它会自动os.Exit(1)，但注意它不走SetOutput设置的输出目标，而是硬编码到os.Stderr
如何按环境开关日志级别（不用第三方库）
Go 标准库没有内置日志级别，但命令行工具常需通过 -v 或 --debug 控制详细程度。最轻量做法是封装一个全局 verbose 布尔变量，配合条件判断。
容易踩的坑是把日志输出逻辑分散在各处，导致漏判或重复判断。建议统一入口：
- 定义
var verbose = false，在flag.Parse()后用flag.BoolVar(&verbose, "v", false, "enable verbose output") - 写一个
debugf(format string, args ...interface{})函数，内部检查if !verbose { return }，再调用log.Printf - 切勿在
debugf里拼接字符串传参（如debugf("x=%s", expensiveToString(x))），即使verbose=false，expensiveToString仍会被执行
log.SetOutput 切换到 os.Stdout 的副作用
命令行工具有时要把日志和正常输出混在一起（比如进度条后跟状态日志），这时会把 log.SetOutput(os.Stdout)。但要注意：标准日志默认是行缓冲的，而 os.Stdout 在连接终端时是行缓冲，重定向到文件时变成全缓冲——这会导致日志延迟出现甚至丢失（进程崩溃前未 flush）。
解决办法很简单，但常被忽略：
- 如果必须输出到
os.Stdout，在每次log.Printf后手动os.Stdout.Sync()（仅限 Linux/macOS；Windows 下无效） - 更稳妥的是用
log.New创建独立 logger，输出到os.Stdout，并用bufio.NewWriter(os.Stdout)包装，但需在程序退出前调用w.Flush() - 最省事：坚持用
os.Stderr输出日志，os.Stdout只给用户数据——这是 Unix 哲学，也规避了缓冲问题
真正麻烦的不是怎么开日志，而是当 --quiet 和 --debug 共存时，或者日志要同时写文件又输出终端——这时候才需要考虑多 writer 分发，标准库就不太够用了。
