readstring('\n')读出'\r'是因为它仅在遇到第一个'\n'字节时停止，不处理前置'\r'；windows文件中为"hello\r\n"，故返回含'\r'的字符串，需手动用strings.trimright(line, "\r\n")清理。
ReadString('\n') 为什么读出来带 \r？
因为 ReadString('\n') 只认字节 '\n'，遇到就停，不管前面有没有 '\r'。Windows 文件里是 "hello\r\n"，它返回 "hello\r\n"；Unix 是 "hello\n"，它返回 "hello\n"。它不剥离、不转换、不报错——你得自己清理。
常见错误现象：line == "done" 判断失败、strings.TrimSpace 后仍多一个 \r、JSON 字段名末尾出现不可见字符、日志行尾莫名多出空格。
- 别用
strings.TrimSpace替代清洗：它会删掉首尾所有 Unicode 空白（包括中文全角空格、零宽空格），可能误伤数据 - 优先用
strings.TrimRight(line, "\r\n")：只针对行尾控制符，行为确定、无副作用 - 若需兼容古老 Mac（
\r单独作换行），加进去：strings.TrimRight(line, "\r\n")
Scanner 和 ReadString，该选哪个？
bufio.Scanner 默认用 ScanLines 分割器，内部调用 bytes.IndexByte 找 \n，再回退跳过前置 \r，返回纯内容——它才是跨平台“按行语义”的标准解法。
ReadString('\n') 更底层、更可控，但要求你手动处理 \r、长行拼接、BOM、缓冲区重置等细节。
- 脚本类工具、配置解析、用户输入处理 → 用
Scanner，省心 - GB 级日志流式清洗、需要精确控制每块读取边界、自定义分隔逻辑 → 用
bufio.Reader+ReadString或ReadLine -
Scanner默认单行上限 64KB，超长行直接 panic；必须处理时，提前调scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)
如何安全检测文件实际行尾？
不能靠扩展名或 OS 猜测。真实行尾是字节级事实：打开文件，读前几 KB，统计 \r\n 连续出现频次 vs 单独 \n 出现频次。
混合行尾很常见（尤其跨平台编辑过的 CSV/日志），所以检测结果只供参考，最终清洗策略仍应统一用 strings.TrimRight(line, "\r\n")。
- 别用
os.ReadFile全量加载来检测——浪费内存，且对几十 GB 文件根本不可行 - 用
bufio.NewReaderSize(f, 4096)读一段，再遍历字节切片计数即可 - 如果文件含 UTF-8 BOM（
\xEF\xBB\xBF），必须先跳过再扫描，否则会影响行尾判断
大文件场景下，行尾清洗不是性能瓶颈
真正拖慢的是频繁分配 string 和 GC 压力。当文件达 50GB，哪怕每行只做 TrimRight，字符串拷贝和内存申请也会成为瓶颈。
这时该放弃“按行”抽象，改用“按块读取 + 状态机解析”：一次读 1MB，手动找 \n 位置，切分并清洗，避免每次调用都触发新 string 分配。
-
ReadString每次返回新string，无法复用底层数组 - 用
reader.ReadSlice('\n')或reader.ReadLine()获取[]byte，配合bytes.TrimRight避免 string 转换开销 - 若后续还要 JSON 解析或正则匹配，直接在
[]byte上操作比转成 string 快 2–3 倍
行尾清洗本身很简单，难的是在不同规模、不同来源、不同编码的文件之间保持行为一致。最易被忽略的是：你以为的“一行”，在字节层面可能是 \r\n、\n、\r 甚至混合；而你写的清洗逻辑，往往只覆盖了其中一种。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
