JSON解析报错SyntaxError常因输入为空、含BOM或纯空白，而非语法错误；UnmarshalTypeError则多因类型不匹配、指针/嵌套字段处理不当或json:",string"标签误用；应通过类型断言捕获错误，避免依赖错误字符串，并优先检查原始数据。
JSON解析报错 SyntaxError：不是格式问题，很可能是输入为空或含BOM
遇到 SyntaxError，第一反应常是“JSON写错了”，但实际多数情况和内容语法无关。Go 的 json.Unmarshal 对空输入、BOM（字节顺序标记）、纯空白（如只有空格或换行）都会直接返回 SyntaxError，错误信息里还带 invalid character ...，极具迷惑性。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先检查输入是否为
nil或空切片：len(data) == 0，这种情况应提前拦截，避免进json.Unmarshal - 读文件或 HTTP 响应时，用
bytes.TrimLeft(data, "\ufeff")去掉 UTF-8 BOM（\ufeff是其 Unicode 表示，对应字节EF BB BF） - 对不可信输入（如用户 POST），用
strings.TrimSpace(string(data))再转回[]byte，排除首尾空白干扰 -
SyntaxError.Offset字段可定位出错字节位置，但注意：它基于原始字节偏移，若你做过string()转换或截断，这个值会失准
UnmarshalTypeError：字段类型不匹配时，别只看结构体定义
UnmarshalTypeError 意味着 JSON 值类型和目标 Go 类型不兼容，比如把 "123"（字符串）往 int 字段塞，或把 123（数字）往 *string 指针里解。但它常被误判为“结构体写错了”，其实更常出在嵌套、指针、自定义类型或零值默认行为上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查字段是否为指针类型：
*string无法接收 JSONnull以外的非字符串值；若想接受字符串/数字都转成字符串，得用自定义UnmarshalJSON方法 - 留意嵌套结构体中未导出字段（小写开头）：它们不会被解，但若 JSON 有同名字段，也不会报错——而是静默忽略，容易让人误以为是类型错配
- 使用
json.Number作为中间类型接收数字，再手动转成int64或float64，能规避整数溢出导致的UnmarshalTypeError - 如果结构体字段带
json:",string"标签，却传了非字符串值（如123），也会触发此错误——标签要求严格匹配字符串形式
如何区分并捕获这两种错误？用类型断言 + 错误链判断
Go 1.13+ 默认开启错误链，json.Unmarshal 返回的错误可能被包装多层。直接用 errors.Is(err, &json.SyntaxError{}) 会失败，因为底层是值比较，而 SyntaxError 是结构体，每次 new 都是不同实例。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用类型断言最可靠：
if serr, ok := err.(*json.SyntaxError); ok { ... }，同理处理*json.UnmarshalTypeError - 不要依赖
err.Error()包含特定字符串来判断——中文环境或未来 Go 版本可能改提示文案 - 若需同时处理多层包装（例如 HTTP handler 中 wrap 过的 error），用
errors.As(err, &serr)，它会递归查找底层匹配类型 - 捕获后别直接返回给前端：暴露
SyntaxError.Offset可能泄露原始数据长度等侧信道信息
性能与兼容性提醒：别在循环里反复调用 json.Unmarshal 解同一类结构
每次调用 json.Unmarshal 都要反射遍历结构体字段、做类型检查、分配内存。如果高频解析固定结构（如日志行、API 批量请求），开销明显。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对稳定结构，用
json.NewDecoder复用解析器：dec := json.NewDecoder(reader); dec.DisallowUnknownFields()，比反复Unmarshal快 10%–30% - 启用
DisallowUnknownFields()可提前捕获字段名拼写错误，但它会让含额外字段的旧版 JSON 报错——上线前确认兼容策略 - 如果结构极简单（如只有几个字段），考虑手写解析（
json.RawMessage+strconv），省去反射成本，但维护成本上升 - 注意：Go 1.20+ 对小结构体做了优化，但差异仍存在；benchmark 时务必用真实数据大小，别只测空对象
最麻烦的不是错误类型本身，而是 SyntaxError 和 UnmarshalTypeError 都可能由上游数据污染引发——比如前端传了没 encode 的中文、代理加了不可见字符、数据库字段被意外存成 JSON 字符串嵌套。查错时别只盯 Go 代码，先抓原始 payload 看一眼 hex。
