go mod replace 是原型阶段唯一靠谱的本地依赖注入方式，通过在 go.mod 中添加 replace 指令使编译器跳过远程解析、直接读取本地路径代码，并需配合删除 go.sum 后执行 go mod tidy 以避免校验和冲突。
能，但必须绕开默认的远程拉取逻辑，否则每次 go run 都卡在下载依赖上，原型就“原”不起来了。
go mod replace 是原型阶段唯一靠谱的本地依赖注入方式
你写了个新模块 github.com/yourname/core，另一个正在草稿中的服务想立刻试用它，又不想推到远程仓库——replace 就是为此设计的。它让 Go 编译器跳过远程解析，直接从本地路径读代码。
- 在主项目的
go.mod末尾加一行：replace github.com/yourname/core => ../core（路径必须是相对当前go.mod的） - 执行
go mod tidy，会自动把replace记录进go.mod，并忽略该模块的版本号 - 注意：被
replace的模块自身也得有go.mod，且module声明要和replace左侧完全一致（包括大小写） - 别在
replace后面加版本号，比如@v0.1.0—— 这会让 Go 忽略replace，转而尝试去 proxy 下载
避免 go.sum 干扰导致构建失败
原型阶段频繁改本地依赖，go.sum 里的校验和很容易和实际文件不匹配，报错类似 checksum mismatch。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 最直接的办法：删掉
go.sum，再跑一次go mod tidy—— 它会重新生成，且只包含当前replace后实际用到的依赖 - 不要手动编辑
go.sum，它的格式是 Go 内部约定的，手改极易出错 - 如果团队协作，记得在 README 里写明：“本原型使用
replace，请勿直接go get拉取依赖”
proto、mock、config 等临时依赖建议直接嵌入 main 包
原型不是产品，没必要为一个临时 mock 数据库写单独模块。过度拆分反而拖慢迭代节奏。
- 把快速验证用的
mockDB、fakeHTTPClient直接写在cmd/app/main.go或internal/testutil/下 - 等接口稳定、逻辑复用率上升后，再抽成
pkg/mock或internal/fake - 用
//go:build prototype构建约束标记隔离原型代码，避免误入正式构建流程
真正卡住原型速度的，从来不是语法或框架，而是模块系统默认假设“所有依赖都已发布”。绕过这个假设需要主动干预，而不是等待它“自动适配”。replace 是开关，go.sum 是缓存，而克制拆分冲动，才是保持原型轻量的关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
