go.sum不是锁文件，仅校验模块zip包及go.mod文件的sha256哈希值以防止篡改；版本选择由go.mod的require、goproxy和本地缓存共同决定，必须提交至git且不可手动编辑。
go.sum 不是 lock 文件，别拿它当 package-lock.json 用
它根本不参与版本选择，只做一件事：校验你下载的模块 ZIP 包和 go.mod 文件内容有没有被篡改。真正决定用哪个版本的是 go.mod 中的 require、GOPROXY 设置、以及本地 $GOPATH/pkg/mod 缓存三者共同作用的结果。
常见错误现象：
删掉 go.sum 后 go build 仍能成功 —— 这不是 bug，说明版本没变、代理没污染；但如果哈希不一致，就会报 verifying github.com/some/pkg@v1.2.3: checksum mismatch 并中断构建。
- 同一模块不同版本必然对应不同哈希；同一版本在不同机器上生成的哈希完全一致
- 手动编辑
go.sum几乎必崩：哈希格式（如h1:xxx=）必须严格匹配，错一个字符就校验失败 -
go mod vendor不会修改go.sum，但vendor/目录本身不参与哈希计算
go.sum 每行两个 h1: 哈希分别校验什么
每行以模块路径 + 版本号开头，后面跟着两个哈希值：
-
h1:xxx是该模块 ZIP 解压后所有.go文件（不含go.mod、测试文件、文档）内容的 SHA256 哈希 -
github.com/some/pkg v1.2.3/go.mod h1:yyy是该模块自身go.mod文件的哈希
使用场景：当你用 replace 指向本地路径或 fork 仓库时，Go 会重新计算并写入新哈希，但旧哈希仍保留在 go.sum 中——因为历史构建可能还依赖它。不要手动删，否则下次 go build 可能触发 checksum mismatch。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
为什么 go.sum 必须提交到 Git，且不能忽略
不提交 go.sum，等于放弃依赖完整性保护。CI 构建、新同事拉代码、甚至你下周重装系统后 go build，都可能拿到被篡改的依赖（比如恶意代理返回带后门的包），而你毫无察觉。
-
go.sum体积小（通常几 KB）、无敏感信息、纯校验用途，没理由加进.gitignore - CI/CD 中应显式运行
go mod verify校验所有依赖哈希是否与go.sum一致 - 配合
GOSUMDB=sum.golang.org（默认开启），Go 会通过透明日志机制比对公共 checksum database，进一步防篡改
go.sum 被自动更新的几种典型场景
go.sum 是动态更新的，但只在明确触发依赖变更操作时才改，不是每次 go build 都动它：
-
go get github.com/sirupsen/logrus@v1.9.3→ 新增或替换对应行（必须带完整语义化版本，不能只写@main） -
go mod tidy→ 补全缺失哈希，或删除未被go.mod引用的条目（注意：可能误删间接依赖的校验） - 手动编辑
go.mod后运行go build或go mod download→ 自动补全缺失哈希
唯一合法更新方式是让 Go 工具链自动写入：改完 go.mod 后运行 go mod tidy。它会下载依赖、校验哈希、追加或更新 go.sum —— 别手动生成，也别复制粘贴哈希。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
