因为bufio.scanner默认单行上限64kb，超长行直接返回bufio.errtoolong；应改用bufio.reader.readline()或readstring('\n')，二者无内置长度限制，但需手动处理换行符和空行边界。
为什么直接用 bufio.Scanner 读行可能出错？
因为 bufio.Scanner 默认限制单行最大 64KB，超长行会直接报 scanner.ErrTooLong。如果你处理日志、导出数据或用户输入的文本，很容易撞上这个坑——不是哈希慢，是根本读不完。
- 改用
bufio.Reader.ReadLine()或bufio.NewReader().ReadString('\n')，它们没硬编码长度限制 - 注意
ReadLine()返回的字节切片可能包含回车符（\r\n），而ReadString()保留换行符，哈希前得统一清理 - 若文件含空行，
ReadString()会返回"\n"，别漏掉这种边界情况
选哪个哈希算法？sha256 还是 xxhash？
sha256 安全但慢，xxhash（非加密）快 5–10 倍，适合校验、去重、分片等场景。99% 的“快速哈希”需求其实不需要密码学强度。
- 装
xxhash：go get github.com/cespare/xxhash/v2 - 哈希一行字符串：
xxhash.Sum64String(line)，比先转[]byte再哈希快（内部做了优化） - 如果必须用
sha256，别用sha256.Sum([]byte(s))，而是复用哈希器：h := sha256.New(); h.Write([]byte(line)); h.Sum(nil)，避免每次分配新 hasher
并发读行 + 哈希真的更快吗？
不一定。磁盘 I/O 是瓶颈时，并发读反而加剧寻道开销；只有在 CPU 密集型哈希（如 sha256）且文件已缓存到内存时，并发才有意义。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 纯 SSD 或 mmap 文件：可起 2–4 个 goroutine，用
chan string分发行，再用固定数量 worker 哈希 - 机械硬盘或大文件未预热：老老实实单 goroutine 顺序读 + 哈希，减少上下文切换和锁竞争
- 别用
sync.Pool缓存xxhash.Digest——它本身轻量，池化反而增加判断开销
哈希结果怎么存才不浪费内存？
每行哈希后如果存成 string（比如 hex 编码），会多占 2 倍空间；存成原始字节或 uint64，省一半以上内存。
-
xxhash.Sum64String(line)直接返回uint64，直接存整数，别转fmt.Sprintf("%x", h) - 用
sha256且需可读性：只在最后输出时 hex 编码，中间流程保持[32]byte数组 - 写入文件时，用
binary.Write(w, binary.LittleEndian, hashUint64)比写字符串快且紧凑
真正卡住性能的，往往不是哈希函数本身，而是你没意识到换行符的歧义、没关掉 scanner 的默认限制、或者在机械盘上强行并发读——这些细节比选算法重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
