json.Marshal只导出首字母大写的字段，小写开头字段被忽略；需用json tag如json:"name"控制键名、omitempty省略空值、-忽略字段；私有字段无论tag均不可序列化。

为什么 json.Marshal 会把 struct 字段转成小写或丢掉？

因为 Go 的 JSON 序列化默认只导出（export）首字母大写的字段，且会按字段名小写形式生成 key。比如 type User { Name string } 序列化后是 {"Name":"alice"}，但若写成 name string（小写开头），该字段根本不会出现在 JSON 中。

解决方法是显式用 struct tag 控制字段名和行为：

• 用 json:"username" 指定 key 名
• 加 omitempty 在值为空时不输出该字段（如 json:"age,omitempty"）
• 用 - 完全忽略字段（如 json:"-"）
• 注意：如果字段是私有（小写开头），无论加什么 tag 都无法被 json.Marshal 访问

如何安全地反序列化未知结构的 JSON 响应？

直接用 json.Unmarshal 到 struct 容易 panic —— 比如 API 返回了新字段、类型不匹配（字符串 vs 数字）、或嵌套结构临时变动。这时候优先考虑用 map[string]interface{} 或 json.RawMessage 延迟解析。

典型做法：

• 先用 json.RawMessage 把不确定的字段“暂存”，避免解析失败
• 对已知字段定义 struct，对动态字段用 map[string]json.RawMessage 接收
• 后续再对 json.RawMessage 单独调用 json.Unmarshal，可捕获具体错误位置
• 别用 interface{} 做顶层接收后再强转，类型断言失败时 panic 不友好

type ApiResponse struct {
    Code int              `json:"code"`
    Msg  string           `json:"msg"`
    Data json.RawMessage `json:"data"` // 不立即解析
}

var resp ApiResponse
if err := json.Unmarshal(body, &resp); err != nil {
    return err
}
// 后续根据 code 决定如何解析 Data
if resp.Code == 0 {
    var user User
    if err := json.Unmarshal(resp.Data, &user); err != nil {
        return err
    }
}

HTTP 请求中处理 JSON 时，Content-Type 和 Accept 怎么设才不出错？

Go 的 http.Client 不自动设置请求头，漏掉 Content-Type: application/json 是服务端返回 415（Unsupported Media Type）的最常见原因；而没设 Accept: application/json 可能导致服务端返回 HTML 错误页而非 JSON。

发送请求前必须手动设置：

• req.Header.Set("Content-Type", "application/json") —— 仅对 POST/PUT 且带 body 时需要
• req.Header.Set("Accept", "application/json") —— 所有 JSON 请求都建议加上
• 读响应时，别依赖 Content-Type 头做解析判断，先检查 resp.StatusCode，再用 json.Unmarshal 尝试解析，错误时看 resp.Body 内容定位问题

遇到中文乱码、浮点数精度丢失、时间格式不一致怎么办？

Go 默认的 json 包对中文会转 Unicode（如 "\u4f60\u597d"），浮点数可能因 float64 表达精度出现 12.300000000000001，时间默认用 RFC3339 但服务端可能用秒级时间戳或自定义格式。

对应解法：

• 中文不转义：用 json.Encoder 并调用 SetEscapeHTML(false)（注意 XSS 风险需自行过滤）
• 浮点数控制：提前转成 string 或用 json.Number 延迟解析，避免 float64 中间表示
• 时间统一：struct 字段用 time.Time + json:"xxx,string" tag，或实现 UnmarshalJSON 方法兼容多种格式（如时间戳、ISO8601、秒级字符串）

最麻烦的其实是嵌套结构里混着不同时间格式或数字类型，这时候靠 struct tag 很难覆盖全部情况，得退回到 json.RawMessage + 手动分支解析。别指望一个通用 struct 能扛住所有 API 版本变更。