go.sum本身不防恶意包，只防篡改；它与go mod verify、gosumdb、goproxy协同构成校验链，单靠提交go.sum到git远远不够。
go.sum 文件本身不防恶意包，只防篡改；真正起作用的是它和 go mod verify、GOSUMDB、GOPROXY 配合形成的校验链。单靠提交 go.sum 到 Git 是远远不够的。
go.sum 校验失败时为什么报 “checksum mismatch”
这是 Go 工具链在下载或构建时发现模块 ZIP 内容哈希与 go.sum 中记录的 h1: 值不一致导致的。常见原因包括：
- 代理缓存污染（比如私有 proxy 返回了被替换过的模块 ZIP）
- 模块作者重新发布同版本 tag（即“re-tagging”，违反 SemVer 但技术上可行）
- 本地
replace指令指向的路径内容被修改，但没触发go mod tidy更新校验和 - 手动编辑了
go.sum却没同步更新对应模块的实际内容
注意：go.sum 不校验代码逻辑是否安全，只确认“这次下载的东西和上次一模一样”。所以即使校验通过，也不能说明该模块没后门。
GOFLAGS="-mod=readonly" 和 go mod verify 的区别
两者都用于强化依赖一致性，但作用时机和粒度不同：
-
GOFLAGS="-mod=readonly"：让所有go命令（如go build、go test）拒绝自动修改go.mod或go.sum。适合 CI 环境或团队约定“只允许显式操作依赖” -
go mod verify：独立命令，遍历go.sum中所有条目，重新下载并校验哈希。它不依赖当前构建上下文，也不检查go.mod是否最新，只专注“文件是否被篡改”
CI 中建议组合使用：GOFLAGS="-mod=readonly" go build + go mod verify。前者防误写，后者做兜底校验。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
GOPRIVATE 如何影响 go.sum 安全校验
设置 GOPRIVATE=git.example.com/myorg/* 后，Go 会跳过对该域名下模块的 GOSUMDB 校验，并且不强制要求它们出现在公共 checksum database 中。这意味着：
-
go.sum里仍会记录这些私有模块的哈希，但不会去sum.golang.org验证其合法性 - 如果私有仓库被入侵、恶意提交并打 tag，
go mod download仍会成功，且go.sum校验也通过（因为哈希匹配） - 此时唯一防线是人工审计私有模块的 commit history 和代码变更
所以 GOPRIVATE 是便利性开关，不是安全开关。用它必须配套内部代码审查流程和私有仓库访问控制。
govulncheck 无法替代 go.sum 的根本原因
govulncheck 扫描的是已知 CVE 数据库中的漏洞模式，而 go.sum 防的是“东西变了吗”。两者解决的是不同维度的问题：
-
govulncheck可能漏掉零日漏洞、未入库的供应链攻击、或业务逻辑层后门（比如某包悄悄上传日志到外部服务器） -
go.sum对这类问题完全无感——只要 ZIP 内容没变，哈希就对得上 - 更关键的是：
govulncheck默认只扫描直接依赖，深层传递依赖常被忽略，除非加-all
真正有效的做法是把 go.sum 当作“完整性基线”，把 govulncheck -all 当作“已知风险快照”，再配合定期人工抽检 go list -m all 输出的全依赖树——尤其是那些不常更新、star 数少、作者不活跃的模块。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
