正确姿势是打开文件后用 io.Copy 流式写入 sha256.New() 哈希器，再调用 Sum(nil) 并格式化为十六进制字符串；须检查 os.Open 和 io.Copy 错误，不可直接对路径字符串调用 sha256.Sum。
用 crypto/sha256 计算文件哈希值的正确姿势
直接读文件流进 sha256.New() 的哈希器，比先读入内存再计算更安全、更省内存，尤其对大文件。别用 ioutil.ReadFile（已弃用）或 os.ReadFile 一次性加载整个文件——容易 OOM。
- 打开文件后，用
io.Copy将*os.File流式写入hash.Hash实例 - 调用
hash.Sum(nil)获取最终哈希字节，再用fmt.Sprintf("%x", ...)转成十六进制字符串 - 务必检查
os.Open和io.Copy的错误，哈希本身不报错，但 I/O 失败会导致结果为空或截断
为什么不能直接对文件路径调用 sha256.Sum
sha256.Sum 是针对 []byte 的快捷函数，它底层仍调用 sha256.New().Write(data).Sum(nil)。传入文件路径字符串（比如 "./data.bin"）只会哈希这个字符串本身，不是文件内容——这是新手最常踩的坑。
- 错误示例：
sha256.Sum([]byte("config.json"))→ 哈希的是这 12 个字符，不是 config.json 文件 - 正确路径处理：先
os.Open，再io.Copy(hash, file) - 若需复用哈希器（如同时算 SHA256 和 MD5），记得每次用前调用
hash.Reset()
小文件 vs 大文件：要不要缓冲区？
默认 io.Copy 使用 32KB 缓冲区，对绝大多数场景已足够。除非你明确压测出 I/O 成瓶颈（比如 SSD 上连续读 GB 级文件且 CPU 利用率极低），否则不用手动指定缓冲区大小。
- 显式控制缓冲区：用
io.CopyBuffer(dst, src, make([]byte, 64*1024)) - 缓冲区过大会增加内存占用，过小会增加系统调用次数；32KB～64KB 是较稳妥的平衡点
- 注意：
os.File本身已有内核页缓存，用户层缓冲区影响有限，优先确保错误处理完整
校验和一致性：跨平台要注意换行符和 BOM
哈希值取决于字节流完全一致。Windows 文本文件带 CRLF、UTF-8 文件可能含 BOM，这些都会改变哈希结果。如果用于校验配置或代码文件，建议标准化处理：
立即学习“go语言免费学习笔记（深入）”；
- 文本类文件：读取后统一转 LF、去除 BOM 再哈希（可用
bytes.TrimPrefix检查 UTF-8 BOM[]byte{0xef, 0xbb, 0xbf}） - 二进制文件（如图片、归档包）：直接按原始字节计算，不作任何转换
- Git 默认对文本文件做换行符规范化，但 Go 哈希工具不会自动适配——你的哈希逻辑必须和消费方约定一致
file.Close() 的调用时机和错误忽略。哪怕只读文件，未关闭也可能在 Windows 上导致后续删/重命名失败；而 io.Copy 返回的 error 若没检查，空文件或权限不足时会静默返回全零哈希。 
