fmt.sscanf 是 go 中按格式解析字符串为变量的函数，需传地址、严格匹配类型，不自动跳过多余字符，易因格式错位或空值导致静默失败，应检查返回项数并优先考虑更健壮的替代方案。
fmt.Sscanf 解析字符串的基本用法
fmt.Sscanf 是 Go 中将字符串按格式解析为变量的常用函数，本质是 fmt.Sscanf(str, format, &v1, &v2, …)。它不会自动跳过空白或忽略多余字符，匹配失败时返回非零错误，且**必须传入变量地址**（否则 panic 或静默失败）。
常见错误现象：fmt.Sscanf("123 abc", "%d %s", a, b) 会编译失败（缺少 &），或运行时写入错误内存；若字符串末尾多出字符（如 "123 abc extra"），fmt.Sscanf 默认不报错，但 b 只取到 "abc"，"extra" 被丢弃。
- 格式动词需与目标类型严格匹配：
%d→*int，%f→*float64，%s→*String - 空格在 format 中表示“匹配任意数量的空白字符（含换行、制表符）”，不是字面空格
- 如果要精确匹配字面空格，用
x20或写死空格并确保输入一致
处理带分隔符的结构化字符串（如 CSV 片段）
用 fmt.Sscanf 解析类似 "name:alice,age:30,city:beijing" 这类键值对字符串并不合适——它不支持命名捕获、无法跳过未知字段、也不处理嵌套或转义。此时应优先考虑 strings.Split + strings.TrimSpace 或正则 regexp.FindStringSubmatch。
但若格式高度固定（如 "user=alice;level=5;active=true"），可配合多个 %s 和分号分隔：
立即学习“go语言免费学习笔记（深入）”；
var name, levelStr, activeStr string n, err := fmt.Sscanf("user=alice;level=5;active=true", "user=%s;level=%s;active=%s", &name, &levelStr, &activeStr) // 注意：这里 %s 会吞掉等号后所有内容直到分号，所以 levelStr 得到 "5"，没问题；但若值含分号就崩了-
fmt.Sscanf不做字段校验，levelStr是字符串，需手动strconv.Atoi - 任何字段缺失或格式错位（如
"user=alice;active=true"缺level），n返回实际成功扫描的项数，err为nil，容易漏判 - 更安全的做法是先用
strings.SplitN(s, ";", 3)拆成三段，再逐段strings.SplitN(part, "=", 2)
为什么有时 fmt.Sscanf 返回 nil Error 却没解析出值？
典型原因是：格式串中用了 %s 但输入字符串紧接着是空白或结束符，%s 匹配失败却未报错，而是跳过并继续后续字段——这属于 fmt 包的宽松行为，但极易掩盖问题。
例如：fmt.Sscanf("123", "%d%s", &i, &s) 中，%d 成功读走 "123"，剩下空字符串，%s 匹配失败，但 fmt.Sscanf 默认不报错，s 保持原值（比如空字符串或零值），err == nil，n == 1。
- 务必检查返回的
n是否等于期望的变量个数 - 对关键字段，建议加边界判断：解析后用
strings.TrimSpace(s)看是否为空 - 避免在 format 中混用
%s和%d处理连续无分隔数据（如"123abc"），%d%s会把"123"给整数，"abc"给字符串；但"12345abc"同样成立，无法区分“12345”和“abc”还是“123”和“45abc”
替代方案：什么时候该放弃 fmt.Sscanf？
当字符串含以下任一特征时，fmt.Sscanf 就不再是最佳选择：
- 字段顺序不固定（如 json 风格键值对）→ 改用
json.Unmarshal或自定义map[string]string解析 - 需要容错（跳过非法行、部分字段缺失）→ 用
bufio.Scanner+ 正则或strings.FieldsFunc - 数值范围或格式需校验（如邮箱、IPv4、ISO 时间）→ 先用
fmt.Sscanf粗提，再用net.ParseIP、time.Parse等二次验证 - 性能敏感且字符串量大 →
fmt.Sscanf内部有反射和格式分析开销，纯strings.Index+strconv手动切片更快
最常被忽略的一点：fmt.Sscanf 的 format 字符串本身是运行时解析的，无法在编译期检查格式动词与参数类型的匹配性——出错只能靠测试覆盖，而不是类型系统兜底。