该用%s而非%v时：仅当确定值为string或[]byte且需原始可读形式，%s直接展开内容不加引号、不转义，%v则对string加引号、对[]byte输出字节序列。什么时候该用 %s，而不是 %v？当你要输出的值**确定是字符串或字节切片**，且希望保持原始可读形式时，%s 是唯一合理选择；用 %v 反而可能引入歧义或多余符号。%s 对 string 和 []byte 直接展开内容，不带引号、不转义控制字符（比如 会真实换行）%v 对字符串会加双引号，对 []byte 则输出类似 [103 111] 的字节序列------这在日志里容易误判为"数据异常"常见错误：把用户输入的 username 用 %v 打印进日志，结果看到 "alice"，误以为引号是系统注入的安全提醒：%s 不做 HTML/SQL 转义，拼接 SQL 或渲染 HTML 时必须先手动清理或改用参数化查询%v、%+v、%#v 三个"v系"占位符到底差在哪？它们本质都是通用格式化，但字段可见性与语法还原度逐级增强，选错会导致调试信息缺失或冗余。%v：只输出值本身，结构体是 {Alice 30}，你得靠上下文猜哪个是 Name 哪个是 Age%+v：强制显示字段名，变成 {Name:Alice Age:30}，适合快速定位字段含义，日志里推荐默认用这个%#v：输出完整 Go 代码语法，如 main.User{Name:"Alice", Age:30}，主要用于生成测试用例或调试反射逻辑，线上日志慎用（太长、含包路径）性能影响：三者底层都走反射，%#v 开销最大；高吞吐服务中避免在热路径用 %#v 打印大结构体%w 不是普通占位符，它只在 fmt.Errorf 里生效%w 的唯一合法位置是 fmt.Errorf 的格式串中，且只能对应一个 error 类型参数；其他地方用它会静默降级为 %v，还可能掩盖错误链。正确用法：fmt.Errorf("failed to parse config: %w", err) → 返回可被 errors.Unwrap 解包的包装错误错误写法：fmt.Printf("error: %w", err) → 编译通过但输出和 %v 一样，且失去错误链语义常见坑：在 log.Printf 或自定义 logger 中误用 %w，导致本该可追溯的错误被扁平化成字符串兼容性注意：Go 1.13+ 才支持 %w，老版本代码升级后要检查所有 fmt.Errorf 调用点浮点数、布尔、指针这些类型该用哪个占位符？别硬记，按输出目的分三类选：要人眼可读就用默认型，要机器可解析就用语法型，要精确控制格式就加修饰符。 文小言 百度旗下新搜索智能助手，有问题，问小言。