go中应直接读os.stdin，无需预检管道；用bufio.scanner逐行读时须检查scanner.err()；大输入建议io.readall或自定义split；多源输入宜试读1字节判断；交互式场景用goroutine+channel解耦，避免syscall非阻塞。
直接读 os.Stdin 就行，别预检是不是管道
Go 中管道输入就是普通文件描述符，os.Stdin 在管道场景下自动关联上游输出，不需要用 os.Stdin.Stat().Mode() & os.ModeNamedPipe != 0 判断。这种预检不仅多余，还容易出错：IDE 终端或 CI 环境可能让 Stat() 返回错误或误报非管道；真实管道中上游提前关闭时，Stat() 可能 panic。
正确做法是默认按流式处理——直接读，有数据就读，没数据就走空逻辑或 fallback 到命令行参数。
用 bufio.Scanner 逐行读，但必须检查 scanner.Err()
这是最常用也最容易翻车的点。很多人写：
for scanner.Scan() {
fmt.Println(scanner.Text())
}
但忽略 scanner.Err() 非 nil 的情况。上游中断、编码非法、磁盘满、甚至 Ctrl+C 中断读取，都会让 scanner.Scan() 返回 false，而错误被静默吞掉。
- 务必在循环后加
if err := scanner.Err(); err != nil { /* 处理 err */ } - 默认单行上限 64KB，大块 JSON 或日志流建议用
io.ReadAll(os.Stdin)或自定义Split函数 - 若需兼容空行或制表符等边界情况，显式调用
scanner.Bytes()而非Text()避免自动 trim
多源输入：先试读 1 字节，EOF 则 fallback 参数
想实现「有管道就处理管道，没管道就用命令行参数」，靠 os.Stdin.Fd() != 0 或 Stat().Size() 都不可靠——终端下 Size() 总是 0，伪 TTY 下 Fd() 可能为 0 却仍有输入。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
真正稳妥的做法是尝试非阻塞读 1 字节：
- 用
syscall.SetNonblock(os.Stdin.Fd(), true)（仅 Unix） - 然后
os.Stdin.Read(buf[:1])，若返回io.EOF或0字节，说明无管道输入，走参数逻辑 - 但注意：设为非阻塞后，后续所有读操作都需手动处理
syscall.EAGAIN，实际项目中更推荐直接用bufio.Scanner+ 超时 context 控制整体读取时限
交互式 CLI 需要非阻塞？用 goroutine + channel，别碰 SetNonblock
标准库不支持对 os.Stdin 设置系统级非阻塞模式（O_NONBLOCK），强行用 syscall 会破坏跨平台性和终端兼容性。
Go 的惯用解法是并发解耦：
- 启一个 goroutine 专读
os.Stdin，用bufio.Scanner或bufio.Reader（复用实例，别每次新建） - 结果发到带缓冲的
chan string，主逻辑用select+time.After控制响应延迟 - 绝对不要在多个 goroutine 里并发调
scanner.Scan()，会丢数据 - 需要单字符响应（如方向键）？换
golang.org/x/term，别硬啃syscall
真正的难点不在“怎么读”，而在“读到一半上游挂了怎么收尾”和“用户 Ctrl+D 后要不要继续跑主逻辑”——这些边界必须显式设计，不能依赖 Scanner 自动退出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
