17370845950

json.Unmarshal报invalid character主因是请求体非合法JSON，如Content-Type错误、含BOM头或未完整读取Body；结构体字段须导出且正确打tag；解析前应校验必需字段非零及字符串长度。

接收 JSON 请求时，json.Unmarshal 为什么总返回 invalid character

常见原因是请求体未正确读取，或 Content-Type 不是 application/json，但 Go 本身不校验这个头——它只管解码字节流。如果前端发的是表单数据（application/x-www-form-urlencoded）却用 json.Unmarshal 解，就会因开头是 key=value 而报错。

实操建议：

• 先检查 r.Header.Get("Content-Type")，非 application/json 时直接返回 400
• 用 io.ReadAll(r.Body) 读完整体，避免后续重复读（r.Body 是单次读取流）
• 把原始字节先打印出来（如 log.Printf("raw: %s", b)），确认是否真为合法 JSON
• 注意 BOM 头：Windows 工具生成的 JSON 可能含 UTF-8 BOM（\xEF\xBB\xBF），需手动截掉

结构体字段怎么写才能让 json.Unmarshal 正确映射

Go 的 JSON 解析依赖字段导出性（首字母大写）和 struct tag。小写字母开头的字段永远无法被赋值，哪怕写了 json:"xxx" 也没用。

关键点：

• 字段必须导出（首字母大写），否则忽略
• json:"name" 指定键名；json:"name,omitempty" 表示该字段为空值时不参与编码，但解码时仍会接收
• 嵌套结构体字段也需导出，否则整个嵌套对象解析失败且无提示
• 数字类型别乱用：int 不能接收 JSON 中的浮点数（如 42.0），会报 json: cannot unmarshal number into Go struct field；改用 float64 或加自定义 UnmarshalJSON 方法

type User struct {
    ID     int    `json:"id"`
    Name   string `json:"name"`
    Active bool   `json:"active"`
    Tags   []string `json:"tags,omitempty"`
}

如何在解析前做基础校验，而不是等业务逻辑里 panic

Go 标准库不提供声明式校验，json.Unmarshal 只负责类型转换。想提前拦截非法输入，得自己加一层。

推荐做法：

• 用指针接收结构体，解码后检查是否所有必需字段非零（例如 if u.ID == 0）
• 对字符串字段加长度限制（如 len(u.Name) > 0 && len(u.Name) ）
• 对时间字段优先用 time.Time + json:"created_at,string" tag，避免字符串格式不一致；若必须用字符串，再额外正则校验格式
• 不要依赖 json.Number 做数值范围检查——它只是字符串包装，仍需转成 int64 或 float64 后比较

用 json.RawMessage 延迟解析有什么实际价值

当请求中某个字段结构不确定（比如 webhook payload 类型多变），或想跳过某段 JSON 的解析开销（如大附件元数据），json.RawMessage 就很实用。它把一段 JSON 字节原样存为 []byte，不触发反序列化。

注意点：

• json.RawMessage 必须是字段类型，不能是局部变量；且该字段必须导出
• 后续要用时，再调用 json.Unmarshal 解到具体结构体，此时才真正校验格式
• 如果原始 JSON 本身无效（比如少括号），延迟解析只是推迟报错时间，不会绕过错误
• 别把它当“万能兜底”：对明确知道结构的字段，用具

  

  体类型更安全、性能更好

type WebhookEvent struct {
    Type string          `json:"type"`
    Data json.RawMessage `json:"data"`
}

// 后续按 type 分支处理
var user User
if err := json.Unmarshal(e.Data, &user); err != nil {
    // 处理 user 结构不匹配
}

解析流程本身不复杂，难的是边界情况：空 body、BOM、浮点当整数、嵌套零值、字段名拼写差异。这些地方一旦漏检，错误往往出现在下游逻辑里，堆栈还看不出源头。