Go模块replace仅在本地go.mod生效，不持久、不可共享；正确做法是提交改动并打语义化版本tag，再通过go get引用远程tag。
Go 模块的本地依赖映射（replace）本身不提供“持久化”能力——它只在当前 go.mod 文件中生效，且仅对本机开发环境起作用；真正能被团队共享、CI 可复现的，只有 go.mod 和 go.sum 的提交状态。
replace 是临时重定向，不是本地安装
replace 不会把代码复制进项目，也不修改模块缓存（$GOPATH/pkg/mod），只是在构建时让 Go 工具链把某个模块路径解析到你指定的本地目录。这意味着：
- 该映射只存在于你写的
go.mod中，别人拉代码后若没运行go mod tidy，可能因路径不存在而报错no matching versions； - CI 环境默认禁用
replace（尤其当设了GOFLAGS="-mod=readonly"），直接构建失败； - 本地路径写成绝对路径（如
/home/you/dev/utils）会导致他人无法复现，必须用相对路径（如./local/utils）； - 被
replace的本地模块自身必须有合法的go.mod，且其中module声明必须与replace左侧完全一致（包括大小写和路径斜杠方向）。
想让本地修改“长期可用”，得靠语义化版本 + Git Tag
如果目标是让某次本地改动能被其他环境稳定引用（比如测试分支、预发环境），正确做法不是长期保留 replace，而是：
- 在本地模块目录下，提交改动并打一个 Git tag（如
v0.3.1-fix-auth）； - 回到主项目，执行
go get github.com/user/utils@v0.3.1-fix-auth； -
go.mod会记录该 tag 版本，go.sum会校验其 commit hash； - 此时删除
replace行，go mod tidy仍能正常解析——因为 tag 已发布到远程仓库，CI 可拉取。
注意：tag 名必须符合语义化版本格式（vX.Y.Z 或带预发布后缀），否则 Go 会拒绝识别为有效版本。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
多模块项目里，replace 路径容易算错
当主模块和被替换模块不在同一级目录时，相对路径基于 go.mod 所在位置计算，不是基于 main.go 或 shell 当前路径。常见错误包括：
- 主模块在
./app，本地库在../lib，却写成replace github.com/x/lib => ./lib（少了一个..）； - 子模块路径含空格或特殊字符（如
my lib），Go 不支持，会报invalid module path； - 用了 Windows 风格反斜杠（
..\lib），虽在 Windows 上可能偶然成功，但跨平台 CI 会失败，一律用正斜杠../lib。
CI 构建前必须清理 replace
生产构建流程里，replace 是危险信号。验证方式很简单：
- 在 CI 脚本开头加一行：
go mod edit -json | grep replace，非空则立即退出； - 或者运行
go mod verify，若失败大概率是replace导致的校验跳过； - 更稳妥的做法：CI 中显式设置
GOFLAGS="-mod=readonly"，这样任何未提交的go.mod修改（包括replace）都会让go build直接报错。
真正需要“本地持久化”的场景，其实是私有模块发布流程没跑通——与其卡在 replace 上反复调试，不如先确认 Git 权限、 GOPRIVATE 配置、以及 tag 是否推送到远端。
