json.MarshalIndent 生成带缩进的 JSON，需传入前缀和分隔符，推荐用空格而非制表符；仅导出字段参与序列化，omitempty 会剔除零值，影响结构对齐。
用 json.MarshalIndent 生成带缩进的 JSON 字符串
直接调用 json.MarshalIndent 就能拿到格式化后的 JSON，它比 json.Marshal 多两个参数：缩进前缀和字段间分隔符。比如想用两个空格缩进、字段用冒号加空格分隔，就传 " " 和 ": "。
常见错误是把第二个参数（前缀）写成 "\t" 后没注意输出环境是否支持制表符渲染，结果在某些日志系统或终端里看起来缩进错乱；更稳妥的做法是统一用空格。
-
json.MarshalIndent(v, "", " ")：无前缀，每级缩进两个空格 -
json.MarshalIndent(v, " ", " ")：整体每行开头加两个空格，再加缩进 —— 一般不需要 - 如果
v是nil或含不可序列化字段（如函数、map 中的func()），仍会返回错误，和Marshal行为一致
处理嵌套结构时缩进层级不生效？检查字段是否导出
Go 的 json 包只序列化导出字段（首字母大写）。如果 struct 里有小写字段，比如 type User struct { name string }，那它根本不会出现在输出里，自然也谈不上缩进——你看到的可能是空对象 {} 或部分字段缺失。
另一个容易被忽略的是嵌套 struct 指针：如果字段是 *Inner 且值为 nil，默认会输出 null，但如果你用了 omitempty 标签，它就会被整个跳过，导致缩进“断层”感。
立即学习“go语言免费学习笔记（深入）”；
- 确保所有要输出的字段名首字母大写
- 用
json:",omitempty"时，注意零值字段（""、0、nil）会被剔除，影响结构对齐 - 测试时别只看顶层输出，用
fmt.Printf("%q", b)看原始字节，确认换行符\n确实存在
HTTP 响应中直接写格式化 JSON 会影响性能吗？
会，但通常可忽略。相比 json.Marshal，MarshalIndent 需要额外遍历生成缩进和换行，对小数据（
生产环境 HTTP 接口基本不该返回格式化 JSON：前端不需要，浏览器开发者工具自己会美化；移动端解析还多占带宽。只有调试、CLI 工具、配置导出等明确需要人眼阅读的场景才启用。
- API 开发中，优先用
json.Marshal，靠客户端或调试工具做美化 - 本地开发调试时，可用
log.Printf("payload: %s", string(b))配合MarshalIndent快速验证结构 - 如果必须返回格式化 JSON（比如一个配置下载接口），记得加
Content-Type: application/json; charset=utf-8，避免中文变\uXXXX
替换默认缩进字符后中文显示异常？注意 UTF-8 编码边界
MarshalIndent 内部按 rune 处理字符串，但如果你传入的缩进符本身含多字节字符（比如用 "│ " 或 emoji 当缩进），可能破坏 JSON 字符串的 UTF-8 对齐，导致某些解析器报错或显示截断。
最稳妥的方式始终是用 ASCII 空格或制表符。另外，Go 1.20+ 对非 ASCII 缩进的支持更稳定，但低版本（如 1.16）遇到非 ASCII 前缀可能静默退化为无缩进。
- 缩进字符串建议限定为纯 ASCII：
" "、"\t"、" " - 避免用中文空格（全角）、不间断空格（
- 如果真要定制符号（如日志中加标记），应在
MarshalIndent输出后再用strings.ReplaceAll替换换行符前缀，而不是塞进第二个参数
缩进只是表象，真正容易出问题的是字段可见性、零值处理和编码上下文。跑通一次 MarshalIndent 很快，但要让它在各种边界条件下稳定输出，得盯住 struct 标签和输入数据的“形状”。
