Go语言读取stdin的唯一可靠方式是用bufio.Scanner并检查scanner.Err()；混用fmt.Scan、bufio.Reader或直接调os.Stdin.Read会导致卡死、丢行、错位。
Go 语言本身没有“语言学习技巧”这一内置机制，所谓“利用语言学习技巧”其实是误读——控制台交互程序的实现只依赖标准库和系统 I/O 行为，关键在于选对输入方式、理解阻塞逻辑、处理边界情况。
fmt.Scan 系列函数适合简单场景，但会吃掉空格和换行
如果你只是读几个用空格隔开的单词或数字（比如 fmt.Scan(&name, &age)），fmt.Scan 足够快且直观。但它把连续空白（空格、制表符、换行）全当分隔符，且无法读到字符串里的空格。
- 用户输
John Doe，fmt.Scan只拿到John，Doe留在缓冲区，下次读取会意外拿到 -
fmt.Scanln强制要求输入以换行结尾，且不接受行尾多余空格，容错差 - 所有
fmt.Scan*函数都依赖os.Stdin的默认行缓冲，无法响应 Ctrl+C 等信号，也不支持超时
bufio.NewReader(os.Stdin).ReadString('\n') 是读整行的可靠选择
要保留用户输入中的空格、制表符甚至中文，必须用 bufio.NewReader(os.Stdin) 配合 ReadString('\n') 或 ReadBytes('\n')。它按行读取，直到遇到换行符为止，返回包含换行符的完整字节序列。
- 记得手动去掉末尾的
\n：input = strings.TrimSpace(input)或input[:len(input)-1]（前提是确定有换行） - 如果用户直接关闭输入（Ctrl+D / Ctrl+Z），
ReadString返回io.EOF，需检查err，否则程序 panic - 不要重复创建
bufio.Reader：一个连接复用同一个 reader，避免缓冲区错位
需要单字符响应（如菜单导航、游戏按键）？别自己调 ioctl 或 SetConsoleMode
想实现类似终端里按 j 下移、k 上移的效果，bufio 和 fmt 都做不到——它们必须等回车。此时必须切换终端原始模式，但跨平台手动处理极易出错：
立即学习“go语言免费学习笔记（深入）”；
- Linux/macOS 忘恢复
TCSETS设置，终端就变“哑巴”，命令输进去没回显 - Windows 下未屏蔽
Ctrl+C，程序直接退出，清理逻辑没机会执行 - 方向键、ESC 序列是多字节（如
\x1b[A），ReadByte()会拆开，导致键识别失败
直接用 github.com/eiannone/keyboard：keyboard.Open() 初始化，keyboard.ReadKey() 获取结构化键值，keyboard.Close() 自动还原终端状态——省掉 200 行系统调用胶水代码。
交互式程序必须分离 stdin 与业务逻辑，否则会卡死
聊天程序、REPL 工具这类持续交互的程序，不能让 fmt.Scan 或 reader.ReadString 堵住主 goroutine。UDP 收消息、HTTP 轮询、定时任务都会被拖住。
- 单独起 goroutine 读 stdin，写入
chan string；网络收发也走各自 goroutine，写入另一chan []byte - 主循环用
select同时监听两个 channel，不假设哪个先来 - stdin channel 建议带缓冲（如
make(chan string, 4)），防止用户狂敲回车时丢失输入 - 别用
fmt.Scanln做循环输入——它内部锁了os.Stdin，并发调用会 panic
真正难的不是读一行字，而是让读、写、网络、定时器互不干扰地跑在同一进程里。缓冲、channel、goroutine 这三样，缺一不可。
