json.unmarshal报invalid character错时，问题多在go结构体字段未对齐或类型不匹配，如大小写错误、缺json tag、int字段对应字符串等；应先用json.valid()验证，再检查字段导出、tag声明及类型兼容性。
json.Unmarshal 报错 invalid character 时怎么定位问题
错误通常不是 JSON 格式本身有问题，而是 Go 结构体字段没对齐或用了不支持的类型。比如字段名大小写不匹配、漏了 json: tag、或者把 int 字段对应到了 JSON 中的 "123" 字符串。
- 先用
json.Valid()检查原始字节是否合法 JSON，避免后续解析白忙活 - 结构体字段必须是导出（首字母大写），且推荐显式加
json:"field_name"tag，别依赖默认映射 - 如果上游可能返回字符串数字（如
"age": "25"），别直接定义为Age int，改用Age json.Number或自定义UnmarshalJSON方法 - 调试时打印原始
[]byte前 200 字符，注意 BOM、控制字符、UTF-8 编码异常 —— 这些不会报“invalid character”但会导致解析失败
嵌套结构体里空字段和 nil 指针怎么安全解包
Go 的 json.Unmarshal 对指针字段很宽容，但容易在访问时 panic。比如 *User 解出来是 nil，你直接访问 user.Profile.Name 就崩了。
- 嵌套字段优先用指针类型（如
Profile *Profile），配合omitemptytag 控制序列化逻辑 - 解包后别急着链式访问，先检查中间层是否为
nil：if user != nil && user.Profile != nil - 想统一处理空值，可以用
sql.NullString风格封装，或用第三方库如gjson直接按路径取值，跳过结构体绑定 - 注意：空 JSON 对象
{}和null解到指针字段行为不同 —— 前者会初始化结构体，后者让指针保持nil
时间字段解析总出错：time.Time 和 string 怎么配对
time.Time 默认只认 RFC3339（如 "2024-03-15T14:23:00Z"），但 API 返回的可能是 "2024-03-15" 或 "1710512580" 时间戳，直接塞进去就 panic。
- 别用原生
time.Time接非 RFC3339 字符串；改用自定义类型 +UnmarshalJSON方法 - 示例：定义
type ISODate time.Time，在UnmarshalJSON里试多种格式（time.Parse多次），任一成功就返回 - Unix 时间戳建议用
int64先接，再转time.Unix()，比强转string → time.Time更稳 - 注意时区：JSON 里没时区信息的日期（如
"2024-03-15"）应明确解析成本地还是 UTC，别依赖time.Local默认行为
性能敏感场景下，json.RawMessage 要不要用
当你只读部分字段、或需要延迟解析子结构时，json.RawMessage 确实能省掉一次反序列化开销，但它不是银弹。
立即学习“go语言免费学习笔记（深入）”；
- 适合场景：API 响应含大段日志/配置 blob，你只关心顶层状态码和错误信息
- 风险点：
json.RawMessage保存的是原始字节引用，如果源[]byte被复用或释放，它会变成脏数据 —— 记得用append([]byte{}, raw...)拷贝一份 - 别用它来“绕过类型检查”，后期维护成本高；真要灵活，不如上
map[string]interface{}或gjson - 基准测试显示：对小于 1KB 的 JSON，用
RawMessage和全量解析性能差异不到 5%；别过早优化
事情说清了就结束。最常被忽略的其实是错误上下文 —— json.Unmarshal 的 error 本身不带偏移位置，遇到大 JSON 时，光看 invalid character 'x' after object key 根本没法修。真要深挖，得自己切片 + 手动扫描，或者换 go-json 这类带行号提示的解析器。
