md5计算需按数据规模选方法：小字符串用md5.sum()，大文件用md5.new()+io.copy()；sum返回结构体，须用hex.encodetostring(sum[:])或fmt.sprintf("%x", sum)取值，不可直接string转换。
Go 里算 MD5 不是“调个函数就行”，关键在选对入口：小字符串用 md5.Sum()，大文件或流式数据必须走 md5.New() + io.Copy()；混用会出错，不是写法问题，是语义冲突。
md5.Sum() 怎么用才不 panic？
md5.Sum([]byte(s)) 返回的是结构体，不是字符串，也不是切片。直接 string(sum[:]) 容易越界 panic，打印出来像 {[138 214 110]} 也不代表失败——那是 Go 默认格式化 [16]byte 的结果。
- 正确取值路径：先
sum := md5.Sum([]byte(s))，再用hex.EncodeToString(sum[:])或fmt.Sprintf("%x", sum) - 别在循环里反复调
md5.Sum()：它不复用，每次都是新结构体，没意义 - 适用场景严格限定：URL、配置键、短文本（
- 如果只是临时比对 key，
md5.Sum()足够；但想复用哈希器（比如连续算多个小串），就得换md5.New()
大文件 MD5 为什么不能用 os.ReadFile？
os.ReadFile("big.zip") 会把整个文件加载进内存，几百 MB 就可能 OOM。这不是 Go 的 bug，是设计使然：md5.Sum() 只接受 []byte，没法流式处理；而 md5.New() 返回的 hash.Hash 才是为流准备的接口。
- 标准流水线只有这一条：打开文件 →
md5.New()→io.Copy(hasher, file)→hasher.Sum(nil)[:] -
io.Copy自动处理缓冲（默认 32KB）、短读、边界，手动Read+Write极易漏掉最后一次n 的字节 - 符号链接默认被跟随；若只想算链接本身（非目标内容），得先
os.Lstat()判断类型 - 空文件能正常算出
d41d8cd98f00b204e9800998ecf8427e，无需特殊分支
UTF-16LE 字符串怎么算 MD5？
Go 标准库不支持 UTF-16 编码，必须用 golang.org/x/text/encoding/unicode。Python 里的 challenge.encode('utf-16le') 在 Go 中不能靠 []byte(s) 模拟——UTF-8 字符串转 UTF-16LE 是变长编码，字节数翻倍且含字节序逻辑。
- 核心是构造转换链：用
unicode.UTF16(unicode.LittleEndian, unicode.IgnoreBOM).NewEncoder()创建编码器 - 再套一层
transform.NewWriter(hasher, enc)，让写入自动编码+哈希 - 别手动
enc.Bytes([]byte(s))：BOM 处理、代理对（surrogate pair）都容易出错 - 生产环境务必检查
t.Write()的 error，尤其是输入含非法 UTF-8 序列时
MD5 还能用吗？什么时候必须切到 SHA256？
能用，但边界非常窄：仅限非安全场景——缓存 key、CDN ETag、内部日志去重、文件下载完整性校验。只要涉及防篡改、签名、密码、token，立刻换 crypto/sha256。
- SHA256 接口和 MD5 几乎一致：
sha256.Sum()返回[32]byte，sha256.New()行为相同，替换成本极低 - 性能差距不到 20%，现代 CPU 上几乎感知不到
- 最常被跳过的是
io.Copy的 error 检查和file.Close()的defer——它们不出现在示例代码里，却在批量任务中十次八次卡住 - 协议强制要求 MD5（如某些老旧固件更新）除外；否则，默认就该用 SHA256
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
