sha256.sum256 是值类型，可直接作为 map key 或结构体字段，适合小数据；sha256.new() 返回 hash.hash 接口，需 write() 后调用 sum(nil) 获取结果，适用于流式处理大文件。
sha256.Sum256 和 sha256.New() 有什么区别？
根本区别在于：前者是固定长度（32 字节）的值类型，适合做 map key 或结构体字段；后者是接口类型 hash.Hash，需要调用 Sum(nil) 才能得到最终哈希值。
常见错误是把 sha256.New() 的返回值直接当结果用，其实它只是个可写入的状态机——你得先 Write()，再 Sum(nil) 才行。
- 如果哈希内容小且已知（比如一个字符串），用
sha256.Sum256更轻量、无内存分配：h := sha256.Sum256([]byte("hello"))直接拿到h就是 [32]byte - 如果要流式处理大文件或网络数据，必须用
sha256.New()+Write()+Sum(nil) -
Sum(nil)返回的是切片，底层数组和sha256.New()内部状态共享；若需长期保存，应拷贝：copy(dst[:], h.Sum(nil))
为什么 hash.Write() 返回 int 和 error？
它模仿了 io.Writer 接口，返回写入字节数主要是为了兼容性，实际中几乎没人检查这个 int；但 error 必须处理——虽然 sha256.Hash 实现永远不会返回非 nil error，其他哈希（比如带 hmac 的）可能在初始化失败时出错。
真实陷阱在于：有人忽略 error，结果在切换到其他 hash 包（如 crypto/sha512 或自定义 wrapper）时埋下静默失败隐患。
- 安全写法永远检查：
n, err := h.Write(data); if err != nil { /* handle */ } - 别假设
n == len(data)——虽然 SHA256 不会截断，但抽象层上这是 io 协议要求 - 如果 data 是 []byte，直接传；如果是 string，用
[]byte(s)转换即可，无需额外 copy（Go 1.22+ 对这种转换做了优化）
计算文件 SHA256 时怎么避免 OOM？
直接 ioutil.ReadFile（或 os.ReadFile）读整个文件进内存，遇到 GB 级文件就崩。正确做法是用 os.Open + io.Copy 流式计算。
注意 io.Copy 内部用 32KB 缓冲区，对绝大多数场景足够高效；自己手写循环读取反而容易出错。
- 典型安全模式：
f, _ := os.Open("big.zip")<br>h := sha256.New()<br>io.Copy(h, f)<br>sum := h.Sum(nil) - 别用
bytes.Buffer中转——它会双倍内存占用 - 如果同时需要文件内容和哈希，才考虑分块读取 + 分别写入 buffer 和 hash；否则纯哈希场景，
io.Copy是最简最稳解法
Hex 编码输出时用 fmt.Sprintf 还是 encoding/hex？
用 encoding/hex。虽然 fmt.Sprintf("%x", sum) 看起来短，但它依赖反射，性能差 3–5 倍，且不支持大小写控制（%x 小写，%X 大写，但没法混用或跳过前缀）。
更关键的是：fmt 在处理非切片类型（比如 sha256.Sum256）时会隐式转成 [32]byte，而 hex.EncodeToString 明确只接受 []byte，语义更清晰、IDE 更易推导。
- 推荐写法：
hex.EncodeToString(sum[:]) // sum 是 Sum256 类型<br>hex.EncodeToString(h.Sum(nil)) // h 是 *sha256.digest
- 如果要大写 hex，用
strings.ToUpper(hex.EncodeToString(...))，别用%X——因为%X对数组和切片行为不一致，容易误判 - 不要在日志里直接打印
sum（即 [32]byte 值），它会被格式化成 32 个数字，难以阅读；务必 hex 编码后再打
事情说清了就结束。SHA256 本身没坑，坑全在周边：类型混淆、忽略 error、内存滥用、编码随意——这些地方松一扣，线上就可能出校验不一致或 OOM。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
