go mod 不能直接配合 Git 分支做依赖版本，因为其仅支持语义化版本（vX.Y.Z）或预发布标签，不识别分支名；分支不稳定、无固定 commit hash，会导致构建不可复现、go.sum 校验失败及协作混乱。
go mod 为什么不能直接配合 Git 分支做依赖版本？
因为 go mod 默认只认语义化版本（vX.Y.Z）或预发布标签（v1.2.3-beta.1），不识别 Git 分支名（如 main、feature/auth）。当你执行 go get github.com/org/pkg@feature/auth，Go 会报错：invalid version: version "feature/auth" does not match pattern。
这不是 bug，而是设计使然：分支是临时、不稳定的状态，而模块系统要求依赖可复现、可校验。直接绑分支会导致构建不可靠、go.sum 校验失败、CI 环境无法复现本地行为。
- 分支没有固定 commit hash 绑定，每次
go mod download可能拉到不同代码 -
go.sum依赖的是模块路径 + 版本号生成的 checksum，分支名无法参与计算 - 团队协作时，A 开发用
main，B 测试用dev，依赖树实际已分裂，但go list -m all看不出差异
如何在敏捷迭代中安全地使用开发分支？
用 replace 指令临时覆盖模块路径，把远程模块映射到本地已 checkout 的分支目录——这是唯一被 Go 官方支持的“分支联调”方式。
假设你在开发 github.com/org/app，想试用 github.com/org/lib 的 feature/login 分支：
立即学习“go语言免费学习笔记（深入）”；
- 先在本地克隆
lib到项目同级目录：git clone -b feature/login git@github.com:org/lib.git ./lib - 在
app/go.mod中添加：replace github.com/org/lib => ./lib - 运行
go mod tidy，此时go list -m github.com/org/lib显示为github.com/org/lib v0.0.0-00010101000000-000000000000 => ./lib - 注意：
./lib必须含有效go.mod（模块路径必须与replace左侧一致）
这个方案只适用于开发机和 PR 验证环境。CI 构建前必须删掉 replace 行，否则会因路径不存在而失败——建议用 GOFLAGS="-mod=readonly" 提前暴露问题。
分支变更如何同步到正式版本号？
敏捷迭代不是绕过版本管理，而是让版本发布节奏匹配交付节奏。分支验证通过后，应立即打语义化 tag，而非合并后才发版。
- 功能开发完、测试通过，在
lib仓库的feature/login分支上运行：git tag v1.5.0 && git push origin v1.5.0 - 回到
app，删掉replace，执行：go get github.com/org/lib@v1.5.0 - 提交更新后的
go.mod和go.sum—— 这才是可审计、可回滚的变更点
不要用 @latest 或 @main 替代 tag。前者隐含版本漂移风险，后者绕过 MVS 算法，可能引入不兼容变更。
多人并行开发多个 feature 分支时怎么避免冲突？
核心是模块边界 + 接口契约先行。每个 feature 分支修改的模块，必须有明确的对外接口定义（如 service.UserRepo），且该接口应声明在独立的 github.com/org/contract 模块中。
- 所有 feature 分支都
replace github.com/org/contract => ./contract，确保接口一致 - 实现模块（如
github.com/org/user）各自维护自己的go.mod，互不干扰 - 主模块
app只 importgithub.com/org/contract，不直接 import 实现 - 这样即使 A 在
user@feature/a、B 在user@feature/b，只要契约不变，就能并行推进
真正容易被忽略的点是：模块间通信必须走接口，而不是包路径。一旦出现 import "github.com/org/user/internal/auth" 这类跨模块引用，replace 就救不了你——重构成本远高于提前定义契约。
