md5哈希值需用hex.encodetostring(sum[:])转字符串，大文件必须流式处理：os.open→md5.new()→io.copy→hasher.sum(nil)[:];校验仅用于完整性比对，禁用于密码或签名。
md5.Sum() 不是字符串，直接打印会看到 {[123 45 67]}
很多人写完 md5.Sum(data) 就用 fmt.Println 打印，结果输出一串带方括号和数字的结构体表示——这不是哈希值，是 Go 把 [16]byte 当成普通数组打印出来的原始内存视图。
-
md5.Sum()返回的是值类型md5.Sum（底层是[16]byte），不是[]byte，更不是字符串 - 要转成可读哈希串，必须先切片：
sum[:]得到[]byte，再用hex.EncodeToString() - 别写
fmt.Printf("%x", sum)—— 虽然能出结果，但这是靠fmt的隐式转换，不直观、难维护，且对流式计算不通用
大文件必须用 io.Copy + md5.New()，不能全读进内存
用 md5.Sum([]byte) 算小字符串没问题，但一碰几十 MB 的文件就可能 OOM。Go 标准库没提供 md5.File() 这种“一键函数”，得自己搭流水线。
- 打开文件后，创建
hasher := md5.New()，它实现了io.Writer - 用
io.Copy(hasher, file)流式写入，底层自动分块（默认 32KB），内存占用恒定 -
io.Copy返回(int64, error)，错误不能忽略：磁盘满、权限不足、网络中断都会在这里报错 - 别漏掉
file.Close()，尤其在循环或并发中，否则 fd 泄露
为什么不用 md5.Sum(nil) 直接算文件？
有人试过 data, _ := os.ReadFile("big.zip"); md5.Sum(data)，短时间能跑通，但这是危险模式。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
os.ReadFile会把整个文件加载进内存，1GB 文件 ≈ 1GB 内存峰值 -
md5.Sum()是栈上计算，适合固定小数据；它不接受io.Reader，没法流式处理 - 就算你硬塞大 slice 给它，GC 压力陡增，还可能触发栈溢出（极少见但可能）
- 真正安全的路径只有一条：
os.Open→md5.New()→io.Copy→hasher.Sum(nil)[:]
校验场景下，md5 仅用于完整性比对，别碰密码或签名
MD5 在 Go 里依然可用，但它的定位已经很窄了：文件下载后校验是否损坏、CDN 缓存 ETag、日志去重等非安全场景。
- SHA-1 已被证实可碰撞，MD5 更早被攻破，两者都不该用于任何需要防篡改的场合
- 如果协议没强制要求（比如某些老旧设备固件更新仍验 MD5），生产环境请无条件切换到
sha256.New() - 同一套流式逻辑，把
md5.New()换成sha256.New()就能升级算法，无需改结构
最常被跳过的其实是 io.Copy 的 error 检查和 file.Close() 的 defer——它们不出现在“Hello World”例子里，却在真实项目里高频导致校验静默失败或文件句柄耗尽。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
