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 延迟解析。
典型做法：
立即学习“go语言免费学习笔记（深入）”；
- 先用
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 版本变更。
