Go语言JSON格式化工具开发教程

本文深入解析了Go语言开发JSON格式化工具时必须掌握的核心实战技巧，涵盖如何安全读取管道输入避免阻塞、正确选择json.Indent与json.MarshalIndent的适用场景、高效处理流式NDJSON数据、排查go run环境下stdin继承异常等高频痛点，同时揭示了IDE终端与原生shell在管道支持上的关键差异，为开发者提供了一套开箱即用、健壮可靠的命令行JSON工具构建指南。

怎么用 os.Stdin 读取管道输入而不卡住

Go 程序从管道读取 JSON 时，如果没判断输入来源，os.Stdin 在无输入时会一直阻塞，导致命令行“假死”。这不是 bug，是 Unix 管道的正常行为：stdin 没被关闭，ReadAll 就不返回。

实操建议：

• 用 stat, _ := os.Stdin.Stat() 判断是否为管道：(stat.Mode() & os.ModeCharDevice) == 0 成立才表示有管道输入
• 别直接 ioutil.ReadAll(os.Stdin) —— 改用带超时或条件检查的读法，比如先 bufio.NewReader(os.Stdin).ReadBytes('\n') 尝试读一行，再根据是否 EOF 决定是否继续
• 如果用户既想支持管道（cat data.json | gojsonfmt），又想支持文件参数（gojsonfmt data.json），优先处理命令行参数，没参数再查 stdin 是否就绪

json.Indent 和 json.MarshalIndent 选哪个

两者都格式化，但语义和使用场景完全不同，混用会导致输出异常或 panic。

实操建议：

• json.MarshalIndent 是“序列化 + 格式化”，适用于你有 Go struct 或 map，想转成缩进 JSON 字符串；它内部会做类型检查、转义、编码
• json.Indent 是“纯格式化”，输入必须是合法 JSON 字节流（[]byte），只负责加缩进、换行，不做解析校验；适合管道场景：原始输入已经是 JSON，只是没排版
• 如果你用 json.Indent 处理含语法错误的 JSON，它会直接 panic 并报 invalid character —— 这是预期行为，不是库问题
• 示例：正确用法是 json.Indent(buf.Bytes(), nil, "", " ")，其中第二个参数 nil 表示不加前缀，第四个是缩进字符串

如何让工具兼容不换行的流式 JSON（如 NDJSON）

标准 json.Indent 要求整个输入是一份完整 JSON（对象或数组），遇到每行一个 JSON 对象（NDJSON）会失败，报 invalid character '\n' after top-level value。

实操建议：

• 不要试图用单次 json.Indent 处理多行 JSON；改用逐行解析：scanner := bufio.NewScanner(os.Stdin)，对每行调用 json.Valid 校验后再 json.Indent
• 注意空行和注释：JSON 标准不支持行内注释，但有些前端工具输出带 // 的伪 JSON；json.Valid 会直接返回 false，需提前清理或跳过
• 性能上，逐行处理比一次性读全更省内存，尤其适合日志类大流量 JSON 流

为什么 go run main.go 管道处理失败，而编译后正常

不是 Go 版本或代码问题，是 shell 启动方式差异导致的 stdin 继承异常。用 go run 时，Go 工具链会 fork 新进程执行，某些 shell（尤其是 zsh + oh-my-zsh 插件组合）可能重置或延迟传递 stdin 状态。

实操建议：

• 调试阶段统一用 go build -o fmtjson && cat data.json | ./fmtjson 验证逻辑，避免被 go run 的环境干扰
• 如果坚持用 go run 测试，加 -ldflags="-s -w" 减少符号干扰，并确保终端未启用 stty -icanon 类似设置
• 真正上线部署时，永远用编译后的二进制——这不仅是管道问题，还涉及 CGO、资源限制、信号处理等隐性差异

最常被忽略的是：开发时在 IDE 终端里跑管道命令，IDE 自己的 shell 环境可能禁用了管道继承，这时候连 os.Stdin.Stat() 都拿不到有效 mode，得切到原生终端验证。

今天关于《Go语言JSON格式化工具开发教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！