json.MarshalIndent用于格式化嵌套map的JSON输出，需确保map键为string、字段导出并正确使用tag；它通过prefix和indent参数控制缩进样式，不改变数据语义，仅美化空白字符。
用 json.MarshalIndent 处理嵌套 map 的基础格式化
直接调用 json.Marshal 生成的 JSON 是紧凑无换行的，对深层嵌套结构几乎不可读。真正起作用的是 json.MarshalIndent —— 它接受两个额外参数：缩进符和前缀（通常传空字符串），比如 json.MarshalIndent(data, "", " ") 表示用两个空格缩进，不加行首前缀。
注意：Go 的 map 键必须是可比较类型（如 string、int），且 JSON 只支持字符串键，所以嵌套 map 中若存在非 string 类型的 key（比如 map[int]string），会在序列化时 panic 报错 json: unsupported type: map[int]string。
- 确保所有 map 的 key 类型都是
string，否则先做键类型转换 - 如果 map 值含自定义 struct，字段需导出（首字母大写）且有对应 JSON tag 或默认命名规则
-
MarshalIndent不改变数据语义，只影响输出字符串的空白字符，性能略低于Marshal，但对调试/日志场景完全可接受
处理 interface{} 混合嵌套时的类型安全问题
实际中常遇到 map[string]interface{} 套多层 interface{}，里面可能混着 float64、bool、nil，甚至未初始化的 map 或 slice。Go 的 json 包会自动把 float64 当数字、nil 当 null，但容易踩的坑是：浮点数精度丢失（比如 3.0 输出成 3），以及 map 值为 nil 时被序列化为空对象 {} 而非 null。
- 若需保留整数/浮点数区分，提前将数字转为
string或用自定义 marshaler - 若某层 map 值可能是
nil且希望输出null，不能直接赋值nil给interface{}字段，而应使用指针或包装类型（如*map[string]interface{}） - 避免在 map 中存函数、channel、unsafe.Pointer 等不可序列化类型，否则
MarshalIndent会返回错误
当嵌套过深导致栈溢出或性能下降怎么办
Go 默认递归深度无硬限制，但极端嵌套（比如上千层 map 套 map）可能触发 runtime 栈溢出，或使 MarshalIndent 执行缓慢。这不是 JSON 库的问题，而是 Go 运行时对 goroutine 栈的保护机制生效。
立即学习“go语言免费学习笔记（深入）”；
- 先确认是否真有必要保留如此深的嵌套——多数情况可通过扁平化 key（如
"user.profile.address.city"）替代多层 map - 若必须保留结构，可改用流式处理：用
json.NewEncoder配合SetIndent，它边序列化边写入io.Writer，内存占用更低，不易爆栈 - 对超大 map，考虑加超时或深度限制逻辑：递归遍历时计数，超过阈值（如 100 层）提前返回错误，避免失控
中文字段名乱码？别忘了 json.RawMessage 和 UTF-8 编码前提
Go 的 json 包默认输出 UTF-8 编码，只要源数据中的 string 值本身是合法 UTF-8（比如从标准库 net/http 读取的请求体、或用 "你好" 字面量初始化），就不会出现乱码。常见误判是终端或编辑器没设 UTF-8 编码，或错误地用 string([]byte{...}) 构造了非法字节序列。
- 不要手动用
utf8.DecodeRune预处理字段名——JSON 库内部已处理 - 若字段名来自外部输入（如用户上传的 JSON），先用
json.Valid校验，再反序列化，避免非法 Unicode 导致后续 panic - 需要保留原始 JSON 片段不解析（比如透传第三方配置），用
json.RawMessage类型存储，它能跳过解析阶段，直接原样插入最终输出
最常被忽略的一点：格式化只是表象，真正决定 JSON 是否“良好”的是结构合理性与语义清晰度。与其花时间调缩进空格数，不如检查嵌套层级是否真的必要——三层以上 map 嵌套，大概率说明数据建模该重构了。
