安全计算大文件sha256哈希的唯一方式是os.open→sha256.new()→io.copy流水线：流式分块（32kb）、内存恒定、错误可检、需defer关闭文件；禁用sha256.sum256处理文件。
用 os.Open + sha256.New() + io.Copy 是唯一安全的流式路径
大文件（哪怕 100MB）直接 os.ReadFile 会触发 OOM，Go 标准库不提供 sha256.File() 这类封装函数，必须手动搭流水线。核心三步不可省略：os.Open 打开句柄 → sha256.New() 创建哈希器 → io.Copy(h, file) 流式喂入。它自动分块（默认 32KB），内存占用恒定，且 io.Copy 内部会处理读错误。
-
io.Copy返回值必须检查：磁盘满、NFS 中断、权限不足都会在这里返回error，忽略等于线上静默失败 - 务必
defer file.Close()，否则 fd 泄露，跑几天后触发too many open files - 机械硬盘上可加
bufio.NewReader(file)包一层提升小块读取稳定性；SSD 上收益极小，可省
别误用 sha256.Sum256 计算文件哈希
sha256.Sum256 是值类型，只适合小数据一次性哈希（如字符串），它不是流式哈希器，不能接收文件句柄或分块写入。常见错误是写成 var s sha256.Sum256; s.Sum(fileBytes)——这实际只是对 fileBytes 做了一次哈希，和文件内容完全无关；更糟的是，如果 fileBytes 是空或没读出来，哈希值永远固定。
-
sha256.Sum256返回[32]byte结构体，sha256.New().Sum(nil)返回[]byte切片，类型不兼容，强行赋值编译失败 - 误把
Sum256{}当作可复用哈希对象反复调用Sum()，结果无任何增量效果 - 若真要用
Sum256，只能先用os.ReadFile加载整个文件——仅限已知小文件（err
输出哈希字符串时，fmt.Sprintf("%x", h.Sum(nil)) 比 hex.EncodeToString 更轻量
哈希值本质是 32 字节原始数据，后续怎么用决定怎么取。做文件一致性校验？直接比对 fmt.Sprintf("%x", h.Sum(nil)) 得到的字符串即可，比 bytes.Equal 整个文件快几个数量级。这个写法不依赖 encoding/hex，代码更干净，性能也略优（尤其短字符串）。
- 别写
fmt.Println(h.Sum(nil))：输出是{[123 45 ]}这种结构体字面量，不是哈希串 - 别写
hex.EncodeToString(h.Sum(nil)[:])：h.Sum(nil)已是[]byte，[:]是冗余操作 - 若需 Base64 编码（如存密码或生成 token），才必须用
h.Sum(nil)或sum[:]转切片再喂给base64.StdEncoding.EncodeToString
空文件、路径不存在、权限错误必须显式处理
生产环境里 os.Open 失败非常常见，但很多人只写 if err != nil { panic(...) } 或直接忽略。CI 环境、容器中路径不存在或权限不足时，程序会静默失败或崩溃，排查成本极高。
-
os.Open可能返回os.ErrNotExist、os.ErrPermission、syscall.ENOTDIR等具体错误，建议用errors.Is(err, os.ErrNotExist)分类处理 -
io.Copy失败时，err可能来自底层Read，比如io.EOF（正常结束）、syscall.EACCES（中途权限丢失）等，不能一概panic - 空文件能正常计算哈希（结果为
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855），无需特殊跳过，但得确保io.Copy成功返回 0 字节并没报错
h.Sum(nil) 不会重置内部状态；如果想连续算多个文件，必须在每次 Sum(nil) 后调用 h.Reset()，否则第二次结果会叠加第一次。
