应先用os.Stdin.Stat()判断是否为管道输入：(stat.Mode() & os.ModeCharDevice) == 0成立才读取，避免ReadAll阻塞；支持管道与文件双模式时优先处理命令行参数，无参数再检查stdin就绪。
怎么用 os.Stdin 读取管道输入而不卡住
Go 程序从管道读取 JSON 时，如果没判断输入来源，os.Stdin 在无输入时会一直阻塞，导致命令行“假死”。这不是 bug，是 Unix 管道的正常行为：stdin 没被关闭，ReadAll 就不返回。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
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。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
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。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要试图用单次
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语言免费学习笔记（深入）”；
- 调试阶段统一用
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，得切到原生终端验证。
