用 bufio.Scanner 读取一行输入最稳妥，它自动处理换行、缓冲和边界情况，避免 fmt.Scanln/Scanf 的截断和卡住问题，需检查 scanner.Err() 并可调 Buffer 扩容。
读取一行输入用 bufio.Scanner 最稳妥
Go 标准库里没有类似 Python 的 input()，直接读 os.Stdin 容易卡住或丢数据。用 bufio.Scanner 是最常用也最安全的方式，它自动处理换行、缓冲和边界情况。
常见错误是用 fmt.Scanln 或 fmt.Scanf：它们对空格、换行敏感，输入 “hello world” 会被截断成 “hello”，且不吞掉换行符，后续读取可能立刻返回空。
- 默认单行上限 64KB，超长会报
scanner.ErrTooLong，需提前调scanner.Buffer扩容 - 遇到 EOF（比如 Ctrl+D）时
scanner.Scan()返回false，别漏判 - 用
scanner.Text()拿字符串，scanner.Bytes()拿原始字节（不含换行符）
scanner := bufio.NewScanner(os.Stdin)
for scanner.Scan() {
line := scanner.Text() // 自动去掉 \n
fmt.Println("got:", line)
}
if err := scanner.Err(); err != nil {
log.Fatal(err) // 别忽略 scanner.Err()
}
需要读二进制或不定长数据就用 io.ReadFull 或 io.ReadAll
交互程序偶尔要读原始字节流（比如粘包协议测试、读图片 base64 输入），这时 bufio.Scanner 会按行切分，不合适。
io.ReadAll(os.Stdin) 简单粗暴，但会把整个输入全加载进内存，用户输几 MB 就占几 MB；io.ReadFull 更可控，适合已知长度的场景（如读固定 4 字节头）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
io.ReadAll在 EOF 时才返回，Ctrl+D 是它的自然退出信号 -
io.ReadFull要传入预分配的[]byte，长度必须精确匹配，否则返回io.ErrUnexpectedEOF - 如果只是想“读到 EOF 前所有内容”，
io.ReadAll比循环Read更简洁
data, err := io.ReadAll(os.Stdin)
if err != nil && err != io.EOF {
log.Fatal(err)
}
// data 就是全部输入的 []byte
fmt.Scanf 只适合简单结构化输入，别当通用方案用
它能解析整数、浮点、字符串，看起来方便，但实际交互中极易出问题：输入多一个空格、少一个换行，就会卡住或错位。
典型现象是程序停在那儿不动了——其实是 fmt.Scanf 还在等符合格式的输入，而用户已经按了回车。
- 只适用于命令行参数式输入（如
123 hello一次输完），不适合逐轮提示的交互流程 -
%s遇到空格就停，%v对复杂结构支持弱 - 错误返回值常被忽略，导致后续逻辑用到零值变量
var n int
var s string
fmt.Print("Enter number and name: ")
_, err := fmt.Scanf("%d %s", &n, &s) // 用户输 "42 foo" 才行，输 "42\nfoo" 就卡住
Windows 下 Ctrl+Z 不触发 EOF？检查终端和 Go 版本
在 Windows 命令行里，按 Ctrl+Z 回车后 bufio.Scanner 有时不退出，而是继续等待。这不是代码写错了，而是终端行为或 Go 运行时兼容性问题。
根本原因是 Windows 控制台对 EOF 的模拟不一致：某些终端（尤其是旧版 cmd）需要严格按 Ctrl+Z + Enter，且不能有后续字符；Go 1.19+ 对此做了优化，但老版本仍可能表现异常。
- 优先用 PowerShell 或 WSL 测试，避免 cmd 兼容性干扰
- 若必须支持 cmd，可在读取前加
fmt.Fprint(os.Stderr, "\x1a")模拟，但不推荐 - 更可靠的做法是约定退出命令（如输入
quit），而不是依赖系统 EOF
真正麻烦的是混合场景：既要读文本又要响应中断信号，这时候得结合 os.Signal 监听 os.Interrupt，而不是死等 EOF。
