fmt.Scanf常因换行符\n残留在缓冲区导致后续输入失败，因其不自动清理、不跳过不匹配字符，严格字面匹配格式；推荐改用bufio.ReadSstring配合strings.Fields等稳健方案。
fmt.Scanf 不是“解析器”，它只是按格式字符串从标准输入流中逐字符匹配并提取值。它不回溯、不跳过不匹配内容、不自动清理缓冲区——用错就卡住或读错。
为什么 fmt.Scanf 经常读不到后续输入
根本原因是换行符 \n 残留在输入缓冲区里，而 fmt.Scanf 遇到非格式要求的字符（比如多余的 \n）会直接失败，且不消费该字符。
- 输入
123\n后调用fmt.Scanf("%d", &a)：成功读取123，但\n留在缓冲区 - 下一次再调用
fmt.Scanf("%d", &b)：立刻遇到\n，不匹配%d，返回err != nil，b不变，缓冲区仍卡着\n - 循环中反复触发这个失败，就出现“重复提示”“卡死”“值没更新”等现象
fmt.Scanf 的格式字符串必须和输入严格对齐
它不是正则，也不是智能分词，而是字面匹配：空格、标点、换行都要一一对应。
-
fmt.Scanf("age:%d name:%s", &age, &name)要求用户必须输入age:25 name:tom（中间不能多空格、不能少冒号） - 输入
age:25 name: tom（name:和tom之间多一个空格）→ 第二个%s会把tom当作下一个 token，但前面多出的空格导致匹配断裂，err返回input does not match format - 含中文或 Unicode 标点时更易失败，
fmt.Scanf对 UTF-8 多字节字符无特殊处理，只当字节流看待
替代方案：什么时候该放弃 fmt.Scanf
除非你控制输入源（如测试脚本喂固定格式数据），否则不建议在交互式程序中依赖 fmt.Scanf 做主输入逻辑。
- 读一行再解析：用
bufio.NewReader(os.Stdin).ReadString('\n')拿整行，再用strings.Fields+strconv.Atoi等拆解，可控性强 - 需要格式校验但又不想写 parser：先
Scanln或ReadString读整行，再用fmt.Sscanf解析字符串（比Scanf安全，不碰 stdin 缓冲区） - 要支持粘连输入（如连续输多个数字空格分隔）：直接用
fmt.Scan，它自动跳过所有空白（包括\n），适合批量读数场景
最常被忽略的一点：fmt.Scanf 的错误不是“没输”，而是“输得不对”——它不会告诉你哪错了，只返回模糊的 err；而缓冲区残留的 \n 会让后续所有输入函数集体失效，这种隐式状态很难调试。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
