go mod init 必须指定明确模块路径，如 example.com/team/project-name，禁止省略或使用模糊写法；go.sum 必须提交且不可手动编辑；replace 仅限开发阶段，ci 需检测并拒绝残留；vendor 按发布形态决策，启用时需同步 tidy 与 vendor；团队须统一设置 go111module=on。
go mod init 必须指定明确模块路径，不能省略
不写模块路径会导致 go.mod 生成 module ""，后续所有 import 路径无法解析，CI 构建直接失败。很多团队在初始化时用 go mod init 不带参数，结果本地能跑（因为 GOPATH fallback 或 IDE 缓存），但别人 clone 后 go build 报错 import "xxx" is a program, not an importable package。
实操建议：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 统一使用
go mod init example.com/team/project-name，路径需与 Git 仓库地址一致（如 GitHub 组织名 + 项目名） - 模块路径必须全小写、不含空格和特殊字符；若用私有域名，确保 DNS 可解析（否则
go get会 fallback 到 HTTPS 探测） - 禁止用
go mod init .或go mod init $(basename $PWD)这类模糊写法——它不保证路径唯一性，跨仓库迁移时极易出错
go.sum 必须提交，且禁止手动编辑
go.sum 是模块校验的唯一依据，删掉或手改会导致 go build 拒绝加载依赖，报错 verifying github.com/xxx@v1.2.3: checksum mismatch。有人为“清理冗余行”删掉部分校验和，结果 CI 拉取的包哈希对不上，整个构建卡住。
实操建议：
-
go.sum和go.mod一样，必须完整提交到 Git，不可忽略 - 更新依赖后，只运行
go mod tidy，它会自动增删go.sum行；不要用文本编辑器删行、排序或合并 - 若遇到校验失败，优先查网络代理（
GOPROXY）、私有模块配置（GOPRIVATE），而不是绕过校验（GOINSECURE）
replace 只用于开发阶段，禁止提交到主分支
replace 是临时解耦手段，但长期留在 go.mod 里会造成版本漂移：某人本地 replace 了 github.com/a/b => ./local/b，提交后别人 go build 失败，报错 cannot find module providing package，因为路径不存在。
实操建议：
- 开发调试时用
go mod edit -replace=old=new，完成后立即go mod edit -dropreplace=old清除 - CI 流水线中强制运行
go list -m all | grep replace，有输出则失败——防止 replace 残留 - 真正需要固定版本的场景，用
require github.com/a/b v1.2.3锁死，而非 replace
vendor 目录是否启用，取决于发布形态而非个人偏好
启用 go mod vendor 并不是为了“离线编译”，而是为了交付可控的依赖快照。但盲目开启 vendor 会导致 go mod tidy 和 go mod vendor 行为不一致：比如 tidy 清理了某个间接依赖，vendor 里却还留着，最终二进制体积膨胀、安全扫描误报。
实操建议：
- 发布 CLI 工具或嵌入式 binary 时启用 vendor，并在 CI 中验证
go build -mod=vendor成功 - 微服务类项目禁用 vendor，靠
go.mod+go.sum+GOPROXY保证一致性更轻量 - 若启用 vendor，每次
go mod tidy后必须立刻go mod vendor，且 diff 提交 vendor/ 下变更——否则本地和 CI 的 vendor 状态不同步
go env -w GO111MODULE=on 这个设置没统一。有人本地没设，go get 仍走 GOPATH 模式，悄悄把依赖装进 $GOPATH/src，再 go build 时看似成功，实际用的是旧版代码。等他提交 go.mod，别人拉下来一跑就崩。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
