Go调试首选fmt.Printf而非fmt.Println，因%+v、%#v、%T能精准显示结构、语法和类型；并发时需防竞态，应加锁、用log包或专用goroutine；上线前须通过变量、构建标签或log.Writer控制调试输出，避免硬删。
Go 里打印调试信息最常用、最直接的方式就是 fmt 包，但它不是“随便 fmt.Println 一下就完事”，不同场景下选错函数或忽略参数细节，反而会掩盖问题、拖慢调试节奏。
什么时候该用 fmt.Printf 而不是 fmt.Println
当你需要看清变量的**原始结构和类型**时，fmt.Println 往往不够用——它会自动加空格、换行，还会对 slice/map 做简化输出（比如只显示前几项），容易误判长度或内容是否为空。
真正调试时优先用 fmt.Printf 配合动词：
-
%v：默认格式，但不带类型；%+v可显示 struct 字段名，适合排查字段赋值遗漏 -
%#v：Go 语法风格输出，能直接复制粘贴进代码测试，对嵌套 map/slice/struct 尤其有用 -
%T：确认接口变量底层真实类型，避免interface{}掩盖类型错误
type User struct {
Name string
Age int
}
u := User{Name: "Alice"}
fmt.Printf("value: %+v\n", u) // value: {Name:"Alice" Age:0}
fmt.Printf("syntax: %#v\n", u) // syntax: main.User{Name:"Alice", Age:0}
fmt.Printf("type: %T\n", u) // type: main.User
fmt.Print* 系列在并发或日志中容易引发的竞态
标准 fmt 函数不是线程安全的——多个 goroutine 同时调用 fmt.Println 可能导致输出错乱（比如两行日志混成一行，或中间插入截断），这在调试 HTTP handler 或定时任务时特别隐蔽。
立即学习“go语言免费学习笔记（深入）”；
临时调试可接受，但一旦发现输出异常，立刻改用：
- 加锁：用
sync.Mutex包一层fmt调用（仅限快速验证） - 换通道：启动一个专用 goroutine 消费日志 chan，串行打印（适合中等频率调试）
- 直接上
log包：log.Printf默认带时间戳且线程安全，开销极小
别为了省一个 import 就硬扛输出混乱。
调试时如何避免 fmt 干扰生产环境
上线后留着 fmt.Println 不仅泄露敏感信息，还可能因 I/O 阻塞影响性能。Go 没有编译期条件宏，但有更可控的做法：
- 用构建标签 + 变量控制：定义全局
var debug = true，所有调试输出包在if debug { fmt... }中，发布前设为false - 用
//go:build debug标签分离调试代码，编译时加-tags debug才包含 - 更推荐：统一走
log.New(os.Stderr, "[DEBUG] ", 0)实例，上线时把它的Writer换成io.Discard
硬删调试语句是最不可靠的方式——下次再要查，又得重加、再编译、再部署。
为什么 fmt.Sprint 类函数比直接打印更值得习惯
调试时经常需要拼接上下文，比如 "user_id=" + strconv.Itoa(id) + " failed"，这种写法易出错且难维护。而 fmt.Sprintf 不仅简洁，还能提前暴露格式错误（编译不报错，但运行时 panic）。
更重要的是，它天然支持延迟求值：
log.Printf("processing item %d: %s", item.ID, func() string {
// 这个闭包只在真正需要打日志时才执行，避免无谓计算
return expensiveToString(item.Data)
}())很多“性能突然下降”的调试，根源就是调试语句里悄悄触发了数据库查询或 JSON 序列化。
