scanwords 比 strings.fields 更适合流式场景，因其边读边切、内存恒定；需显式调用 scanner.split(bufio.scanwords)，循环用 scanner.scan() + scanner.text() 获取单词，不适用空白不敏感或需保留分隔符的场景。
直接用 bufio.Scanner 配合 bufio.ScanWords 就能按单词拆分输入，比手动 strings.Fields 更省内存、更流式，尤其适合处理大文本或标准输入流。
为什么 ScanWords 比 strings.Fields 更适合流式场景
它不等整行读完再切分，而是边读边识别单词边界（空白符分隔），缓冲区里一有完整单词就返回，内存占用恒定；而 strings.Fields 必须先把整行加载进内存再切，遇到超长行或超多空格容易卡住或爆内存。
常见错误：用 scanner.Text() 拿到整行后再 strings.Fields —— 这等于放弃 Scanner 的流式优势，还可能因默认 64KB 行限制触发 ErrTooLong。
-
ScanWords自动跳过所有 Unicode 空白字符（包括 \t、\r、\n、全角空格等），无需额外 trim - 返回的单词不含任何空白，也不含换行符，
scanner.Text()结果就是纯单词字符串 - 遇到连续多个空白、开头结尾空白，完全静默跳过，不会返回空字符串
怎么启用 ScanWords 并正确读取
必须显式调用 scanner.Split(bufio.ScanWords)，默认是 ScanLines，不设就还是按行读。
实操建议：
- 初始化后立刻设置：
scanner := bufio.NewScanner(os.Stdin); scanner.Split(bufio.ScanWords) - 循环中仍用
scanner.Scan()判断是否拿到下一个单词，不是scanner.ScanLines()（这函数不存在） - 每次成功后用
scanner.Text()取单词，长度可直接用len(scanner.Text())，别用len(scanner.Bytes())后续再转——Text()已是最轻量访问方式 - 如果需保留原始字节（比如含不可见控制符），改用
scanner.Bytes()，但注意它返回的是内部缓冲区切片，下一次Scan()会复用内存，需立即拷贝
ScanWords 在 Windows 输入下会出问题吗
不会。它底层用的是 bufio.ScanWords 函数，对 \r\n 的处理和 ScanLines 一致：把 \r\n 当作单个空白序列跳过，不残留、不卡死、不污染单词内容。
容易踩的坑：
- 混用
fmt.Scan或fmt.Scanf后立刻接ScanWords——fmt留下的换行符会变成第一个“单词”前的空白，虽不影响结果，但首次Scan()可能略慢（要跳过缓冲区里的 \n） - 误以为
ScanWords能识别标点：它只按空白切，"hello,"和"hello"是两个不同单词，逗号属于单词一部分；如需分词更细，得自己写SplitFunc - 没检查
scanner.Err()—— 比如输入被中断（Ctrl+D / Ctrl+Z），Scan()返回 false 后，必须用scanner.Err()区分是 EOF 还是真实 I/O 错误
什么时候不该用 ScanWords
当单词定义不满足「空白分隔」时，比如 CSV 字段含空格、JSON 字符串含引号内空格、或需要保留原始分隔符位置，ScanWords 就不再适用。
此时应退回到 bufio.Reader + 手动解析，或用 scanner.Split() 自定义切割逻辑：
- 自定义分隔：比如按逗号切，写一个
SplitFunc查找,，注意处理引号包裹的字段 - 混合读取：先读一个数字，再读一整行带空格的描述——必须用
bufio.Reader，ScanWords无法回退或切换模式 - 性能敏感且单词极短（如单字符）：
ScanRunes比ScanWords更合适，它按 Unicode 字符切，且能正确处理中文、emoji
真正难的不是选哪个函数，而是意识到 ScanWords 不是万能分词器——它只解决“空白分隔的单词流”，其余都得自己兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
