手动编辑go.mod的require行仅在依赖已被代码import且版本格式合法时才安全，否则go mod tidy会删除或替换它；replace需目标路径存在有效go.mod且module声明匹配，多条replace映射同一路径会报错。
go.mod 里 require 怎么写才不会被 go mod tidy 覆盖
手动编辑 require 行只有在满足两个前提时才安全：一是该依赖已被代码实际 import，二是版本号格式合法。否则 go mod tidy 会直接删掉它，或替换成 Go 工具链自动解析出的版本。
常见错误现象：go mod tidy 后刚加的 require github.com/xxx/v2 v2.1.0 消失了；或者版本被降级成 v2.0.0+incompatible。
- 确保包路径与代码中
import语句完全一致（包括v2、/subpkg等后缀） - 版本号必须是可解析的：支持语义化版本（
v1.2.3）、伪版本（v0.0.0-20240101000000-abcdef123456），但不能写latest或master - 如果依赖未被任何
.go文件 import，go mod tidy会认为它是冗余项并移除
replace 指令为什么有时不生效
replace 只影响当前模块构建，且优先级高于远程源，但它不是“全局重定向”，更不是 go get 的下载目标。很多开发者误以为写了 replace github.com/a/b => ./local-b 就能绕过网络拉取，结果 go build 仍报错找不到包。
典型触发场景：本地路径不存在、路径拼写错误、或 replace 目标本身没有 go.mod 文件。
-
replace目标目录必须包含有效的go.mod，且其module声明需与被替换路径匹配（例如被替换的是github.com/a/b，则./local-b/go.mod第一行必须是module github.com/a/b） - 若 replace 到 HTTPS 地址（如
replace github.com/a/b => https://git.example.com/a/b v1.2.0），Go 会跳过下载，只在构建时按需 fetch —— 这不是“预下载”，也不触发go mod download - 多个
replace映射到同一路径时，Go 会报错replaced by multiple modules，必须清理冲突
go.sum 校验失败时能不能手动删某一行
不能。删掉某行 go.sum 条目只会让下次 go build 或 go mod tidy 重新生成它，且可能因缓存污染导致哈希不一致，进而触发 checksum mismatch 错误。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
真正的问题往往不在文件本身，而在本地缓存或代理中间层污染了 zip 包内容。
- 先运行
go mod download -dirty强制重拉校验失败的模块（仅限调试，生产慎用） - 检查
GOPROXY是否包含私有域名：若依赖来自internal.corp.com，需提前设置GOPRIVATE=internal.corp.com，否则 Go 会走公共代理并写入错误哈希 - 确认
go.sum文件没被 IDE 或 Git hook 自动格式化（比如把空格转成 tab，破坏哈希行结构）
go mod download all 是不是真能离线构建
不是绝对的。“go mod download all” 下载的是 go list -m all 输出的所有模块，但它不保证覆盖所有构建路径——特别是含 //go:embed、cgo 或条件编译（// +build linux）的依赖，可能在 go build 阶段才首次触发下载。
离线前必须验证的三件事：
- 执行
go build -a -v .，观察输出是否还有Fetching日志；若有，说明某些模块未被go list -m all捕获 - 确认
GOPROXY=direct且GOSUMDB=off已生效（注意：后者仅用于可信环境，放弃校验） - 检查
go.mod中是否有replace指向远程 URL —— 这类替换在download all阶段会被忽略，构建时才会去抓
最稳妥的做法是：在联网环境下跑一次完整 go build -a -v，等所有 fetching 完成后再打包整个 $GOPATH/pkg/mod 缓存目录。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
