可以，但必须用@显式标注分支名或commit hash，如go get github.com/user/repo@main；若报unknown revision，需先查commit并生成pseudo-version手动写入go.mod。
go get 能否直接拉取特定分支
可以，但必须用 go get 的完整 commit hash 或带 @branch-name 的形式，且模块仓库需启用 Go modules（即根目录有 go.mod）。单纯写 go get github.com/user/repo@main 通常无效——Go 默认只认 tagged 版本，除非该分支被显式允许。
- 有效写法是：
go get github.com/user/repo@v1.2.3（tag）、go get github.com/user/repo@commit-hash（精确 commit）、go get github.com/user/repo@branch-name（仅当 branch 有对应 pseudo-version 或本地已缓存） - 如果
@main报错unknown revision main，说明 Go 尚未为该分支生成 pseudo-version，此时需先用git ls-remote查 commit，再用 hash 替代 -
go.mod中最终记录的仍是 pseudo-version（如v0.0.0-20230405123456-abcdef123456），不是分支名
在 go.mod 中硬编码分支对应的 pseudo-version
手动编辑 go.mod 是最可靠的方式，尤其当你需要长期锁定某个开发中分支时。Go 不会自动更新已写死的 pseudo-version，也不会因远程分支更新而改变依赖。
- 先运行：
git ls-remote https://github.com/user/repo.git refs/heads/main，取回最新 commit hash（如abcd123...） - 生成 pseudo-version：格式为
v0.0.0-YEARMONTHDAY-HOURMINUTESECOND-COMMIT，例如v0.0.0-20240510142200-abcd12345678 - 在
go.mod中替换原有行：require github.com/user/repo v0.0.0-00000000000000-000000000000→require github.com/user/repo v0.0.0-20240510142200-abcd12345678 - 执行
go mod tidy验证是否能 resolve，失败则说明 commit 不可访问或未公开
为什么 go.sum 里会出现两个同一模块的不同版本
当你同时依赖 A 和 B，而 A 依赖 github.com/x/y@v1.0.0、B 依赖 github.com/x/y@main（解析为 pseudo-version），Go 会保留两者并存于 go.sum。这不是错误，而是模块版本隔离机制的正常表现。
-
go.sum每行对应一个具体 commit 的校验和，不同 pseudo-version 视为不同模块版本 - 若想统一，需让所有依赖都指向同一 commit（或 tag），否则
go build仍能工作，但二进制体积可能略增、调试时需注意实际加载的是哪个 commit -
replace可强制全局重定向，但仅作用于当前 module，下游用户不受影响
用 replace 绕过版本约束直接指定本地或远程分支
当需要快速验证某分支改动，又不想改 go.mod 中的 require 行时，replace 是最灵活的选择，它优先级高于 require。
- 写法示例：
replace github.com/user/repo => github.com/user/repo v0.0.0-20240510142200-abcd12345678 - 也可指向本地路径：
replace github.com/user/repo => ../repo-fork（要求本地目录含有效go.mod） - 注意：
replace不会出现在go list -m all的输出中（除非加-u），且go mod vendor会把替换后的内容拉进去 - 上线前务必删掉
replace，否则 CI 构建可能失败（尤其当本地路径不存在时）
@main 命令成功，往往是因为之前已拉过该分支、Go 缓存了对应 pseudo-version；一旦缓存失效或换机器，就得手动补 commit hash。 
