md5.Sum()适合短文本、URL、配置键等一次性小数据哈希；需用hex.EncodeToString(sum[:])转字符串，避免直接打印或string()转换。
小字符串用 md5.Sum()，大文件或流式数据必须用 md5.New() 配合 io.Copy()；混用会出错，不是“写法不同”，是语义根本冲突。
md5.Sum() 适合什么场景？怎么用才不踩坑？
md5.Sum([]byte(s)) 返回一个结构体，内部字段是固定大小的 [16]byte 数组，只适合一次性输入、长度可控的数据（比如 URL、配置键、短文本）。它不维护状态，也不支持多次 Write。
- 直接打印
md5.Sum([]byte("hello"))会看到类似{[138 214 110 ...]}的输出，这不是错误，是结构体默认格式化——得取hash[:]再转十六进制 - 别写
string(hash[:])：可能含不可见字节，且越界 panic 风险高 - 正确转字符串：用
hex.EncodeToString(hash[:])或fmt.Sprintf("%x", hash)（后者更轻量） - 如果只是校验缓存 key 或临时比对，
md5.Sum()足够简洁；但别把它塞进循环里反复 new 结构体——没意义，它不复用
md5.New() 为什么必须搭配 io.Copy()？手动 Read+Write 错在哪？
md5.New() 返回的是 hash.Hash 接口实例，设计目标就是流式写入。它内部管理缓冲区和状态，但你不该自己模拟这个过程。
- 错误做法：开
buf := make([]byte, 4096)，循环file.Read(buf)再hash.Write(buf)—— 容易漏掉最后一次n < len(buf)的剩余字节，导致 MD5 错误 -
io.Copy(hash, file)是标准解法：它自动处理边界、缓冲（默认 32KB）、短读，且对hash.Hash有底层优化路径 - 若真要手动控制缓冲区（极少数场景），用
io.CopyBuffer(dst, src, buf)，但buf长度只影响内存占用，不影响结果 - 别写
md5.New().Sum([]byte("x"))：参数是拼接缓冲区，不是待哈希数据，结果会多出 "x" 的字节
计算文件 MD5 时，哪些错误路径容易被忽略？
空文件、符号链接、权限不足、路径不存在……这些不是哈希逻辑的问题，但会在 os.Open 或 io.Copy 阶段直接失败。
立即学习“go语言免费学习笔记（深入）”；
- 空文件能正常算：
md5.Sum([]byte(""))对应d41d8cd98f00b204e9800998ecf8427e，无需特殊判断 - 符号链接默认被跟随；若只想算链接文件本身（而非目标内容），需先
os.Lstat判断类型，再决定是否os.Open -
permission denied、read xxx: is a directory这类错误来自系统调用，不是md5包的问题，必须显式检查err - 别用
os.ReadFile或ioutil.ReadFile加载大文件——几百 MB 就可能 OOM，违背流式设计初衷
MD5 还能用吗？什么时候必须换 SHA256？
MD5 在 Go 标准库中仍可用，编译无警告，但它的适用边界非常清晰：仅限非安全场景的完整性校验。
- 可用于：下载后比对
md5sum值、生成缓存 key、去重标识、内部系统临时校验 - 禁用场景：密码存储（哪怕加盐）、JWT 签名、API 认证、数字签名、任何需要抗碰撞或防穷举的环节
- 替换方案：直接换
crypto/sha256，接口完全一致（sha256.Sum()/sha256.New()），CPU 开销差异可忽略，I/O 才是瓶颈 - 别信“MD5 快一点”——现代机器上算法耗时远低于磁盘读取，选型优先看安全要求，不是微秒级差异
真正卡住上线任务的，从来不是“怎么写一行代码”，而是空文件处理、符号链接行为、错误返回值是否检查、以及——把 md5.Sum() 当成万能函数塞进文件读取逻辑里。
