Sprintf是格式化函数而非拼接工具，返回新字符串且不修改原值；应优先用于类型转换或格式控制场景，避免在热路径滥用，纯字符串拼接推荐+或strings.Builder。
Go语言中Sprintf拼接字符串的正确姿势
Sprintf本质是格式化输出到字符串，不是“拼接函数”。它不修改原字符串，而是返回新字符串——这点和strings.Join或+拼接逻辑不同，但更安全、更可控。
常见误用是把它当“累加器”反复调用：str = Sprintf("%s%s", str, next)，这会触发多次内存分配，性能差且易读性低。
- 优先用于带类型转换或格式控制的场景，比如：
Sprintf("user_%d_%s", id, name) - 纯字符串拼接（无格式需求）建议用
+（小量）或strings.Builder（大量、循环中） -
Sprintf底层调用fmt.(*pp).doPrintf，有反射开销，别在 hot path 上滥用
为什么Sprintf返回string而不是error？
因为它的格式串在编译期静态检查（如"%d"配int），只要格式合法、参数类型匹配，就不可能失败。所以签名是func Sprintf(format string, a ...interface{}) string，不返回error。
但一旦格式错误，运行时 panic，例如：Sprintf("%d", "hello")会触发panic: fmt: %d does not support string。
立即学习“go语言免费学习笔记（深入）”；
- 开发期可用
go vet捕获大部分格式错误 - 线上避免用用户输入直接作
format参数，否则可能 panic 或信息泄露 - 若需动态格式，先校验再调用，或改用
fmt.Sprintf+recover（不推荐，掩盖设计问题）
Sprintf vs fmt.Sprint vs 字符串+：选哪个？
三者语义和成本差异明显，不能混用：
-
Sprintf("%s", x)→ 强制转string，支持Stringer接口，但有格式解析开销 -
Sprint(x)→ 无格式，自动调用String()或默认格式，比Sprintf轻量 -
x + y + z→ 编译器优化后接近strings.Builder，仅限string类型，不可用于int等原始类型
举例：拼接name string和age int，必须用Sprintf("%s:%d", name, age)；若全是string，name + ":" + strconv.Itoa(age)更高效（但可读性略降）。
容易被忽略的兼容性坑：%v在结构体上的行为
用Sprintf("%v", struct{A, B int}{1, 2})返回{1 2}，空格分隔、无字段名——这和json.Marshal或fmt.Printf("%+v")完全不同。
-
%+v才输出字段名：{A:1 B:2} -
%#v输出 Go 语法风格：main.T{A:1, B:2} - 跨包传递结构体日志时，别只依赖
%v，字段顺序/空格/括号都可能影响解析或比对
真正需要稳定字符串表示的场景（如缓存 key、日志摘要），应显式定义String()方法，而非依赖Sprintf默认行为。
