json.MarshalIndent 已完备支持缩进、换行、字典序键排序及嵌套美化，无需手动实现；应直接使用 interface{} 处理未知结构，避免 map[string]interface{} 导致数组解析失败；流式输入需用 io.ReadAll + TrimSpace；验证优先选 json.Compact。
用 json.MarshalIndent 就够了，别自己写缩进逻辑
Go 标准库的 json.MarshalIndent 已经完整覆盖缩进、换行、键排序（按字典序）、嵌套结构美化等需求，不需要手动拼接字符串或递归处理。它底层复用 json.Marshal 的序列化逻辑，语义一致、无额外解析开销。
常见错误是试图先 json.Marshal 得到紧凑字符串，再用正则或字符串替换加空格——这会破坏转义（比如 "\n" 变成实际换行）、忽略 Unicode 处理、且无法保证嵌套层级对齐。
实操建议：
-
json.MarshalIndent第三个参数是每级缩进用的字符串（常用" "或"\t"），第四个是对象内键值对之间的前缀（一般为空字符串） - 如果输入是
[]byte，先用json.Unmarshal解析成interface{}再重 Marshal，否则无法美化原始字节流（可能含多余空格或换行） - 注意：它不会修改原始数据结构，也不做类型转换（比如把
int64强转成float64），行为可预测
处理未知结构时，interface{} 是唯一安全入口
JSON 数据来源不可控（如 HTTP 响应体、文件读取），字段名和嵌套深度不确定，此时不能预定义 struct。必须走 interface{} 路线，由 json.Unmarshal 自动推导类型树。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是强行用 map[string]interface{} 接收顶层——这会丢失数组开头的 JSON（如 [1,2,3]），导致 Unmarshal 报错 invalid character '[' looking for beginning of value。
实操建议：
- 统一用
var v interface{}+json.Unmarshal(data, &v)，它能正确处理对象、数组、基础类型任意组合 - 后续若需校验或提取，再用类型断言（
v.([]interface{})或v.(map[string]interface{})），但格式化阶段无需这步 - 注意浮点数精度：JSON 中的数字默认解析为
float64，若原始是整数但值超2^53，可能丢失精度——不过格式化本身不放大该问题
命令行工具场景下，别忽略 os.Stdin 的 EOF 和编码
写成 CLI 工具时，用户常通过管道传入 JSON：curl ... | go-run-jsonfmt。这时直接读 os.Stdin，但容易卡住或读不全。
典型现象是程序挂起，或只输出第一行；根源是未处理流式输入的结束信号，或没考虑 Windows 行尾（\r\n）干扰 JSON 解析。
实操建议：
- 用
io.ReadAll(os.Stdin)一次性读完，不要用bufio.Scanner（默认 64KB 缓冲，大 JSON 会截断） - 读取后 trim 空白符（
bytes.TrimSpace），兼容前后多余的空格、换行、BOM - 如果输入为空（
len(data) == 0），提前返回错误，避免Unmarshal报unexpected end of JSON input
性能敏感时，json.Compact 比 MarshalIndent 快 3–5 倍
如果只是想“验证 JSON 是否合法 + 去掉冗余空白”，而非真正美化，用 json.Compact 更合适。它不生成换行和缩进，只做最小化压缩，内部跳过格式化路径，纯解析+重序列化。
在 CI 日志清洗、配置预检等场景，省掉缩进计算能明显降低延迟，尤其对 MB 级 JSON。
实操建议：
- 先
json.Compact，成功后再决定是否调MarshalIndent（比如加个-prettyflag 控制） -
json.Compact输入必须是有效 JSON 字节，且不接受带注释或 trailing comma 的非标准 JSON - 它不会改变数值精度或字符串转义行为，和
MarshalIndent底层共享同一套 encoder
缩进字符选空格还是 tab，表面是风格问题，实际影响 diff 可读性和 IDE 折叠逻辑——但 Go 标准库不做强制，交由第三个参数控制，这点很务实。真正容易被忽略的是：当输入含非法 UTF-8 字节时，json.Unmarshal 会静默替换为 \uFFFD，而格式化结果里看不出异常，得靠前置校验。
